From 0a14ee5a409ba15bdd787e32e61cb588dba1fcdf Mon Sep 17 00:00:00 2001
From: Kevin Zheng
Date: Tue, 26 Mar 2024 13:56:57 -0700
Subject: [PATCH 01/80] Identify things that are already implemented
---
src/en/proposals/notafet-atmos.md | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/en/proposals/notafet-atmos.md b/src/en/proposals/notafet-atmos.md
index 658f55d8e..d9f3ebff5 100644
--- a/src/en/proposals/notafet-atmos.md
+++ b/src/en/proposals/notafet-atmos.md
@@ -24,7 +24,7 @@ Make atmos more fun and intuitive to play by adding more devices, engines, and p
Using just the devices that already exist, there are some tweaks that can significantly improve gameplay in atmos by making it possible to effectively respond to events like fires or hull breaches.
-- **Globally increase MaxTransferRate** for devices that are not flow-based, e.g. pumps.
+- ~~**Globally increase MaxTransferRate** for devices that are not flow-based, e.g. pumps.~~ (implemented in [atmos speedup](https://github.com/space-wizards/space-station-14/pull/22372))
- This solves problem (2). Among other things, it would make scrubbers and other devices actually useful for combating atmospheric problems. Currently players prefer to just space everything. Increasing this would provide a feasible alternative.
@@ -52,7 +52,7 @@ These principles suggest changes to devices:
- Heaters and freezers are the only "true" unary devices. Even vents/scrubbers which appear unary actually operate on flow from the tile atmosphere into the pipe net.
-- **Make heaters and freezers thermodynamically sound.** Keeping a station properly heated or cooled is actually a substantial real-life problem. Because of the existence of generators like the TEG, keeping things thermodynamically balanced is also a great way to prevent infinite power hacks.
+- ~~**Make heaters and freezers thermodynamically sound.** Keeping a station properly heated or cooled is actually a substantial real-life problem. Because of the existence of generators like the TEG, keeping things thermodynamically balanced is also a great way to prevent infinite power hacks.~~ (implemented as a part of [atmos speedup](https://github.com/space-wizards/space-station-14/pull/22372))
## New Stuff
@@ -60,9 +60,9 @@ This list isn't meant to be exhaustive. Some of the ideas discussed here aren't
- **A "substation" but for gas,** "gas manifold", distribution station, or whatever you want to call it. This would encourage distro to be at high pressure (for higher transfer rates) but then gas distribution stations scattered around the station would bring it down to a normal pressure that is released to vents. Adds antag complexity and gives atmos techs more control.
-- **Add gas condensation.** This would enable fractional distillation and permit conversion between gas and the equivalent reagent.
+- ~~**Add gas condensation.** This would enable fractional distillation and permit conversion between gas and the equivalent reagent.~~ (implemented in [#22436](https://github.com/space-wizards/space-station-14/pull/22436))
-- **Space heaters** to correct local temperature problems.
+- ~~**Space heaters** to correct local temperature problems.~~ (implemented in [#25250](https://github.com/space-wizards/space-station-14/pull/25250))
- **Make station air flow-based.** Currently, air vents release air when the pressure is too low, and by default scrubbers only scrub waste gases. So if for some reason the station gets cold, there's no easy way to cycle the air out and heat it up. Of course, one could set all the scrubbers to siphon, heat their distro, and then set the air alarm to fill. But that would just be describing a bad way of doing what real life HVAC systems have always been doing: keep the air flowing.
From 8350526c4d05de45e9e45ca49a0719ed70949eff Mon Sep 17 00:00:00 2001
From: nikthechampiongr <32041239+nikthechampiongr@users.noreply.github.com>
Date: Sun, 31 Mar 2024 00:30:06 +0000
Subject: [PATCH 02/80] Add minutes for the 2024-03-16 admin meeting. (#192)
Adds the latest admin minutes.
The minutes have been sanitized of sensitive information but otherwise
provide a clear record of the agenda and what happened in the meeting.
---
src/SUMMARY.md | 1 +
.../admin-meeting-2024-03-16.md | 246 ++++++++++++++++++
2 files changed, 247 insertions(+)
create mode 100644 src/en/admin-meetings/admin-meeting-2024-03-16.md
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 736cf140a..31e75c7b4 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -257,3 +257,4 @@ Admin Meetings
----------------------
- [2024-02-03](en/admin-meetings/admin-meeting-2024-02-03.md)
- [2024-02-17](en/admin-meetings/admin-meeting-2024-02-17.md)
+- [2024-03-16](en/admin-meetings/admin-meeting-2024-03-16.md)
diff --git a/src/en/admin-meetings/admin-meeting-2024-03-16.md b/src/en/admin-meetings/admin-meeting-2024-03-16.md
new file mode 100644
index 000000000..31a069328
--- /dev/null
+++ b/src/en/admin-meetings/admin-meeting-2024-03-16.md
@@ -0,0 +1,246 @@
+# Admin Meeting 2024-03-16
+
+## Agenda
+
+- Brief updates from last meeting
+- Ghost role antag rolling
+- Async Trialmin Promotions
+- Character Impersonation
+- Early access blocks from admins
+- Reduction votes without reduction times
+- Review minutes
+
+## Topic Details
+
+### Brief updates from last meeting
+
+The last meeting's minutes are available at [link removed]
+
+#### Summary
+
+> It's been a month since the last meeting. Two big things from the last one were SOP and space law. Those changes are awaiting the rest of the rule changes currently being worked on.
+> -Chief_Engineer
+
+#### Meeting Goals
+
+1. Communicate updates related to items from the last meeting to admins attending the meeting.
+
+### Ghost role antag rolling
+
+#### Summary
+
+> Some people are joining multiple servers at once or within a short period, possibly trying to get ghost roles. Some of these people have been banned for antag rolling. It should be kept in mind that there are other reasons people might appear to be doing this. For example, people might observe a server thinking that the round will end soon, perhaps because they checked the round time, but then discover that the station seems fine and the round is unlikely to end soon, so they leave and do the same on another server. People may also be looking for something interesting to observe or participate in.
+>
+> Here are some appeals that I think are related:
+> - [link removed]
+> - [link removed]
+> -Chief_Engineer
+#### Meeting Goals
+The purpose of this topic is to determine the opinions of attending admins on the following questions:
+
+1. If this is a violation of a rule, which rule?
+2. Are any of the following relevant when determining if a situation violates a rule:
+ 1. Whether the player is taking ghost roles or just observing
+ 2. Whether the player is on multiple servers at the simultaniously
+ 3. Whether the player is taking an antag vs non-antag ghost role
+ 4. Whether the player takes roles on the first server vs leaving it without taking a role
+3. If being on multiple servers simultaniously is not required to violate a rule, then to avoid issues, presumably they have to spend a long enough period of time on each server, or a long enough time between leaving one and joining another to avoid issues. Roughly, what are those times?
+4. Is it reasonable for a player who has read the rules to know all of this?
+5. When is it reasonable to ban players for this?
+ 1. Is it reasonable to place a ban without prior warnings specifically for this?
+ 2. Is it reasonable to place a ban without prior warnings specifically for this, but with warnings for typical antag rolling?
+6. Should any of this be against the rules?
+
+### Async Trialmin Promotions
+#### Summary
+
+> We talked about this during the last batch and now we get to again. Typically, trialmin promotions have all happened at once. As groups get bigger, this is less feasible. Voting on all trialmins at once means each candidate is looked over less carefully and specific candidates occasionally draw attention, which may lead to the other candidates being neglected in the discussion. Waiting for all trialmins to be ready to do a vote means some trialmins will be held back for little reason. Asynchronous promotion can cause tension between trialmins. With one vote at a time, doing 48 hour votes for 6 trialmins would take 12 days. With two at a time, it would take almost a week.
+>-Chief_Engineer
+
+#### Meeting Goals
+
+1. Determine the general feelings and concerns of attending admins about asynchronous vs synchronous promotions.
+
+### Character Impersonation
+
+#### Summary
+
+> There are varying levels of impersonation. You can "impersonate" or copy:
+> - Character name
+> - Character appearance
+> - Character personality
+> - Usernames
+> - lookalikes: COOL = C00L
+> - SS13 usernames that aren't taken on SS14
+> - alterations: SomePlayer = SomePlayerOfficial = Some_Player
+>
+> You can also create any combination of those.
+>
+> Impersonating characters outside of SS14 and SS13 is outside the scope of this topic. It is primarily covered by name rules.
+>-Chief_Engineer
+
+#### Meeting Goals
+
+The purpose of this topic is to determine the opinions of attending admins on the following questions:
+
+1. When, if ever, does impersonation become an issue?
+2. Does it make a difference if the impersonation is:
+ 1. Between two wizden players
+ 2. Between a wizden player and a player of another SS14 server
+ 3. Between a wizden player and a player of a SS13 server
+ 4. Impersonation with an OOC component
+ 5. Impersonation paired with an OOC factor, like a feud that does not rise to harassment
+ 6. Impersonation where the goal appears to be to primarily or also impersonate an OOC identity
+3. Partially discuss the real example that CE will share
+
+### Early access blocks from admins
+
+#### Summary
+
+> What do admins feel is necessary prior to leaving playtest? I've been reminded that we're supposed to be tracking this, so I updated the issue, but I want to make sure I'm not missing stuff.
+>
+> These should all be things that are necessary, or nearly necessary, for game admins to handle a significant surge of players and whatever else may come from leaving playtest. While the issue is not specific to admin things, things that are not specifically related to admins are out of scope for this topic.
+>
+> https://github.com/space-wizards/space-station-14/issues/23246
+>-Chief_Engineer
+
+#### Meeting Goals
+
+1. Create a list of things that are necessary, or nearly necessary, for game admins to handle a significant surge of players and whatever else may come from leaving playtest.
+
+### Reduction votes without reduction times
+
+#### Summary
+
+> Can we put what time you want if you vote for reduction, Currently if not one mentions a time it defaults to 1 week. But if someone votes for something like 2 months and there are another 6 admins that did not define something that is a huge difference in reduction. Adding a time would be useful here.
+> Another thing to keep in mind is the ban time. Reductions are a reduction from a indef ban to a set time, not altering the start date of said ban. If they have already been banned for 2 weeks and we reduce to 1 week it was the same as if we had just removed.
+>-Repo
+
+> I think if people don't care enough to write out what they want the reduction to, then there's no issue with however many do care enough from determining the reduction time on their own.
+>
+> For reductions, I don't think it makes sense to reduce from the start of the ban because it makes two of the vote options actually mean the same thing sometimes instead of actually being different options. I think every time I've been asked, I've told people to reduce from the time that the vote was put up.
+>-Chief_Engineer
+
+#### Meeting Goals
+
+1. Determine if admins should be required to specify a reduction time if voting to reduce a ban.
+2. Determine if the time since the ban was placed is something admins are suggested to add to appeal votes.
+
+### Review minutes
+
+#### Summary
+
+> The meeting minutes provide a record of the meeting for those who could not attend, and they are used to action decisions made in the meeting. For these reasons, it is important that they accurately represent what actually happened in the meeting.
+>-Chief_Engineer
+
+#### Meeting Goals
+
+1. Ensure that nothing important is missing or misrepresented in the minutes.
+2. Attempt to ensure that all topics have met their meeting goals. This can be done by ensuring that each meeting goal is directly addressed by the conclusion of the topic's minutes.
+3. Attempt to ensure that all conclusions fit into one of the following categories:
+ 1. Indicate that a meeting goal was completed.
+ 2. Are something actionable, meaning that they not only call for an action, but that action is specific enough that it does not require answering questions like "what exactly needs to be done?" or "how can this be done?"
+ 3. Clearly indicate that the meeting goals for the topic were not met. Examples: the discussion was tabled, the admin team did not reach a conclusion, the admin team was not able to make the conclusion actionable.
+
+```admonish info
+
+## Attendees
+- Chief_Engineer - Headmin
+- Skarlet - Project Manager, Mediator
+- Retequizzle - Project Manager
+- ShadowCommander - Project Manager
+- nikthechampiongr - Propermin, Minutes Editor
+- TurboTracker - Propermin
+- CptJeanLuc - Propermin
+- Repo - Propermin
+- Crazybrain - Propermin
+- Rose - Propermin
+- Sphiral - Propermin
+- Whisper - Propermin
+- Eclipse - Propermin
+- Lucky - Propermin
+- Kezu - Propermin
+- XxSWAG_MASTERxX - Trialmin
+- lunarcomets - Trialmin
+- Geekyhobbo - Trialmin
+
+```
+
+## Minutes
+
+### Brief updates from last meeting
+
+- LRP space law and SOP awaiting rule change.
+
+### Ghost role antag rolling
+
+- Some players tend to hop between servers in order to get ghost roles. This is usually due to them not wanting to play further in a round they are a part of, as well as other reasons. They will also mostly take antag ghost roles, rather than neutral or otherwise passive ghost roles.
+- Players trying to get ghost roles is not against our current rules.
+- Players "antag rolling" for ghost roles do take up server slots as they often stay afk waiting for those roles.
+- This issue could be resolved much more effectively through code. E.g. Stopping stoping from joining multiple servers at once.
+- Rule zero could be considered where players are systematically taking slots in multiple servers at the same time solely for the purpose of becoming ghost antags. This kind of enforcement should ideally be reviewed by a PM, and go through stricter scrutiny than usual.
+- Alternatively we can just enforce that players should not connect to multiple wizden servers at the same time, however this should be solved by code eventually.
+- Any way of dealing with this through moderation will take up a lot of admin resources that may not be worth it.
+- Players should not be expected to know this is being enforced. As such should we moderate this behavior in any way, at most we should warn players doing this if they present no other issues.
+
+```admonish info "Conclusion"
+
+
+
+Players simply trying to get ghost roles is not an admin issue, not addressed by the rules, and should be solved by code. Where larger issues arise is where players take up slots in multiple servers for prolonged periods of time day after day this is still not directly addressed by the rules. In those cases we can stop those players through role 0 if it's dire enough and even still at most the player should be warned. A simpler way to deal with this issue would be to just require players not play on multiple wizden servers at the same time.
+
+```
+
+### Async Trialmin Promotions
+
+- Asynchronous votes/promotions could only be made in exceptional circumstances. For example(This list is not authoritative. In any case this should be decided on a case by case basis.):
+ - Severe misconduct which will likely lead to the trialmin's removal following a vote.
+ - Retired admins coming out of retirement who already have knowledge and experience of how to be an admin. Even still, after enough time retired admins will likely still require a full trialmin phase. Such votes should be heavily scrutinized.
+ - Trialmins taking extended holidays having their votes delayed compared to others.
+- Asynchronous promotions can cause a lot of friction for trialmins that were not promoted. In order to avoid this the promotion of other trialmins should be held back until that trialmin is either promoted, or removed.
+- Trialmins may also have no problem with asynchronous votes, in which case it would be fine to promote certain trialmins faster than others.
+
+
+```admonish info "Conclusion"
+
+
+
+We could either require all trialmin promotions be synchronous except for special circumstances, or go forward with async promotions all the time. No conclusion was reached other than just discussing the pros and cons of these options. Further discussion is required.
+
+```
+
+### Character Impersonation
+
+- We commonly get problems with players impersonating other well known player characters or even characters of staff members.
+- Players sometimes end up with the same character names by chance, usually this is fine because their character will also look differently.
+- Players who intentionally try to impersonate others can cause major issues for the ones they impersonate. Regardless of our rules on meta-grudging, players will inherently treat a character differently depending on who they know them as.
+- This currently can fall under the "Don't be a dick", or "Notable characters" rule however this would be better addressed by amending our naming rules.
+- There is also the posibility of players trying to imitate another's username. In these cases we can simply use the "Don't be a dick" rules.
+- Enforcement of these kinds of rules starts and ends on our servers only.
+- [details of real example provided by CE] Currently the details are still unclear, but it looks like this is not for us to enforce.
+
+```admonish info "Conclusion"
+
+
+While 2 characters randomly having the same name is usually fine, players intentionally impersonating others can cause major issues. In such cases we should enforce against this using the "Don't be a dick", or "Notable characters" rule for now where these players are acting maliciously and consider amending our naming rules. Should a player try to immitate another's username to harass them we can similarly take action against that. Additionally in most cases handling these issues for chracters between servers are usually outside of our purview.
+
+```
+
+
+### Early access blocks from admins
+
+- Mass actions. This includes bans, freezes, and similar admin actions that we can use against coordinated rule breakers. Covered by [this issue](https://github.com/space-wizards/space-station-14/issues/13270).
+- Toolshed is not finished, and not sufficiently documented. Most admins are unable to use it effectively, and the those that can have only limited uses for it.
+
+### Reduction votes without reduction times
+
+- Topic tabled due to lack of time.
+
+### Discussion outside Agenda Items
+- Trialmin review procedure needs improvement. Currently reviews are often delayed and as a result hold back trialmins.
+
+## Overall Conclusion
+- Ghost role antag rolling only really presents a problem when players hog slots in multiple servers at the same time for prolonged periods. In aggregious cases we can warn players not to do it under rule zero after approval. We can also simply require that players don't connect to multiple servers at the same time but this ideally is a coder issue.
+- No overall conclusion on async promotions of trialmins was reached and requires furhter discussion.
+- Character impersonations become a problem when a player maliciously and intentionally impersonates another. We can use for the "Don't be a dick", or "Notable characters" rule in those case and should consider amending our naming rules to better protect against this.
+- The only new admin blocker that was brought up is toolshed.
From b923f9d0be2715038d79f03b6223d5010c3fe627 Mon Sep 17 00:00:00 2001
From: Peptide90 <78795277+Peptide90@users.noreply.github.com>
Date: Tue, 2 Apr 2024 23:00:06 +0100
Subject: [PATCH 03/80] Update mapping.md - Atmos, telecoms, beacons + (#193)
Adds new atmos stuff:
- Air Alarm
- Fire Alarm
- Air Sensor
- Gas Recycler
- Gas Condenser
----
- Adds mention for the telecoms server.
- Reformatted the warp points section so it starts with station beacons
as the preferred method with warp points as an exceptional circumstance.
- Some more minor edits like putting some commands in code snippets,
added a hint, removed some bloat.
- Adds a tiny heading for escape pod mapping.
Mapping wiki is in a sorry state of maintenace so since I wrote the
majority of it in the first place thought I'd come back and start to fix
it.
---
src/en/space-station-14/mapping.md | 36 ++++++++++++++++++++----------
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/src/en/space-station-14/mapping.md b/src/en/space-station-14/mapping.md
index 50962d4bf..d947f0439 100644
--- a/src/en/space-station-14/mapping.md
+++ b/src/en/space-station-14/mapping.md
@@ -56,7 +56,7 @@ If you choose not to do this, you will need to download a [recent server build](
## Start Mapping
Now to start creating maps follow the below steps:
-1. Start both the client and server. On Windows, this can be done by launching both the "runclient.bat" and "runserver.bat" files in your cloned repository directory.
+1. Start both the client and server. On Windows, this can be done by launching both the "runclient.bat" and "runserver.bat" files in your cloned repository directory, after building the project / solution at least once.
2. Once the game client loads up, connect to the server.
3. Press the backtick/tilde key ` to open the debug console, which allows you to run console commands.
4. Run the `mapping [MapID] [MapFile]` command to either create a new map or edit an existing one.
@@ -89,7 +89,7 @@ The actions toolbar allows you to assign entity, tile, and decal placement actio
To assign an entity to a slot, you can just open the entity placement window and click on an entity to start placing it. Clicking on an empty toolbar slot instead of somewhere in the game world will save that entity to that slot. If you are currently in the entity-eraser mode, clicking on an empty slot will instead create a shortcut to the erase-mode. You can assign tile-placement actions in a similar way. Note that tile deletion is simply the same as placing down space-tiles. Finally, to assign decal actions you need to open the decal menu and configure your decal selection. Once again, clicking on an empty slot will add that decal to the toolbar. You can't save a decal-erasing shortcut to the toolbar, as this requires the decal placement window to be open. To remove an action from a slot, simply right click that slot (assuming the action toolbar has not been locked/frozen).
-A preset collection of mapping actions can be loaded to the toolbar by using the loadmapacts command. Note that as actions are unique to the currently controlled entity, if you use ghost or possession commands you will lose these actions and will have to re-run the command.
+A preset collection of mapping actions can be loaded to the toolbar by using the `loadmapacts` command. Note that as actions are unique to the currently controlled entity, if you use ghost or possession commands you will lose these actions and will have to re-run the command.
## Multi-Grid and Multi-Station Maps
A station and a grid are not the same thing. For example, each asteroid is not it's own station, while a station may consist of multiple grids (e.g. escape shuttles). Most maps only have one grid, though you do still have to set up stations regardless. However, since you can use savemap and loadmap to save/load maps with multiple grids, there is support for overriding this behaviour.
@@ -149,7 +149,7 @@ If your map is now complete, follow the attached checklist [here](https://hackmd
- To remove tiles use the "Space" tile.
- You do not need to place plating down first then tiles, you can just place any tile and it will pry up to show the below tile in game (usually plating).
- Similary you can overwrite tiles by placing a new one in its place - no need to remove them first.
-- Be careful when placing new tiles that they are part of the correct grid - place them from on top of an existing tile if bulk placing or making sure it snaps to an existing tile.
+- Be careful when placing new tiles that they are part of the correct grid - place them from on top of an existing tile if bulk placing or making sure it snaps to an existing tile. Run `lsgrid` in console periodically to check you haven't created more grids.
## Entity Spawner and Placement
- Search for entities using their ID in the search bar, then you can add it to your action bar on the left side for later use by clicking with ig selected into a slot.
@@ -158,12 +158,12 @@ If your map is now complete, follow the attached checklist [here](https://hackmd
## Atmospherics
-If you added new rooms or changed layouts, you need to fix roundstart atmos after making those changes. Use the fixgridatmos [Grid euID] command to do this. (Press F3 or run lsgrid to find your grid euID)
+If you added new rooms or changed layouts, you need to fix roundstart atmos after making those changes. Use the `fixgridatmos [Grid euID]` command to do this. (Press F3 or run lsgrid to find your grid euID)
If you're creating a new map from scratch instead of editing an existing map, then you might want to add an atmosphere to it. There are two commands for this, depending on your needs.
-* If you want your map to have a working atmosphere simulation. (gasses spread, etc), use addatmos 2 Where "2" is the grid ID.
-* If you want your map to have a static atmosphere. (gasses don't spread no matter what), use addunsimulatedatmos 2 Where "2" is the grid ID.
+* If you want your map to have a working atmosphere simulation. (gasses spread, etc), use `addatmos 2` Where "2" is the grid ID.
+* If you want your map to have a static atmosphere. (gasses don't spread no matter what), use `addunsimulatedatmos 2` Where "2" is the grid ID.
### Mapping Atmospherics Components
In order to create a life support system aboard your map you'll need to create a pipe network or two - one for **distributing** air, and one for pulling **waste** gasses out of the air. Use the following devices in your pipe networks (pipe net):
@@ -175,12 +175,17 @@ In order to create a life support system aboard your map you'll need to create a
* **Valves** - Used to manually close off sections of your pipe net. Useful to be placed before a passive vent to space.
* **Pumps** - Used after a passive vent to control the amount of gas pumping into a network. Use these after your gas storage tanks.
* **Atmos Markers** - If you're mapping gas storage tanks, be sure to use the "Atmos Fix (gas) Marker" in the entity spawner to set the tanks to the correct gas. This ensures when you run the fixgridatmos command it puts the correct gas in the tanks.
+* **Air Sensor** - Used to connect logic and sensing to other devices to trigger them. Used specifically for Air Alarms and Fire Alarms.
+* **Air Alarm** - Used with Air Sensors in order to detect harmful atmospheric conditions on areas and feed alerts to Engineering / Atmospherics. Use machine linking to connect air sensors in **adjacent** rooms to the air alarm, as well as vents and scrubbers in the **current room** to the air alarm. Also connect the firelocks between rooms to the air alarm so that it can trigger them to block off sections.
+* **Fire Alarm** - Used to trigger firelocks in the current area. Use machine linking to link it directly to firelocks in it's room or section.
+* **Gas Recycler** - Converts carbon dioxide to oxygen and nitrous oxide to nitrogen when the input gas is pressurized to 3 MPa and heated to at least 300 C.
+* **Gas Condenser** - Converts gasses into reagents. Probably more important to chemistry or science than atmospherics.
### Standard Pipe Colors
-Prefer using standard pipe colors for your atmospherics layout so that players and other mappers can understand it better.
+Prefer using standard pipe colors for your atmospherics layout so that players and other mappers can understand it better. Consider an in service ship or station won't often have vibrant colors.
-- Waste loop: #990000 (pleasing dull red)
-- Distro loop: #0055cc (popping subdued blue)
+- Waste loop: #990000 (dull red)
+- Distro loop: #0055cc (subdued blue)
- Air: #03fcd3 (cyan)
- Mix: #947507 (brownish)
@@ -217,10 +222,12 @@ Palettes can be selected in the decal menu. These are commonly used colors like
You can add your own palettes very easily. Simply go to Resources/Prototypes/Palettes, copy one of the templates into a new file, and change the ID/name as well as the colors you'd like to use. The colors are in the hex format RRGGBBAA.
-## Warp Points
+## Warp Points, Station Beacons and Station Maps
All maps need warp points so observers can get around quicker.
-Find the warp point in the entity spawner, place it, then right click, debug, view variable, navigate to serverside components, search for the warp component, then alter the name in that component to reflect what you want in the warp menu.
+Most maps now will use **Station Beacon**s instead of warp point as they already include the named warp point component on them. Place these in the relevant rooms of your station **instead** of warp points. This will allow them to populate station maps correctly.
+
+If you want to allow people to ghost warp to a location but don't want it to show up on a station map, or it's not suitable for a station beacon (planets, player griefing by moving the warp point, other reasons) then use the classic purple warp point marker. Place it, then right click, view variable, navigate to serverside components, search for the warp component, then alter the name in that component to reflect what you want in the warp menu.
## Naming Doors and Editing Signs
View variable (VV) is your friend. Right click an entity such as a door or sign and navigate to the server variables tab. In here you can edit the name and description of any entity on your map.
@@ -229,7 +236,6 @@ Use this to name specific doors on your map or give flavor to warning signs and
## Vehicle Spawners
- To map vehicles, similar to animals, you need to use the spawner and not the actual entity.
-
- Once mapped make sure to also map a set of keys.
## Cameras
@@ -239,6 +245,9 @@ Use this to name specific doors on your map or give flavor to warning signs and
- If you want to test your cameras view, save your map then run mapinit. You can then view the camera monitor and check their view, make sure to run togglelight in console to get the actual view.
- For entertainment cameras, follow the same process as above but with cameras marked (entertainment).
+## Telecoms
+Stations require a telecommunication server in order for headsets and radios to work correctly. Make sure to place a `TelecomServerFilled` somewhere on your map and sign post it and put a station beacon in there.
+
## Machine Linking (Multitool, Blast Doors, Conveyors etc)
Machine linking works exactly how it does in game. Spawn yourself a multitool from the entity spawner and with it in hands, click on your entity you want to link (conveyors, blast doors, shutters etc) then click on a suitable input such as a button, switch or lever. Then select the way you want to link it, in most cases, default linking is best.
@@ -249,6 +258,9 @@ To enable the cargo shuttle for testing on a local server, run the following in
sudo cvar shuttle.cargo true
+## Escape Pods
+To map escape pods, simply map the docking airlock with the suffix `escape 3x4`. Make sure to leave a 3x4 gap of space outside the dock for it to spawn when the map is initialised, plus at least a tile of space around that gap for logical reasons.
+
# Planets
This is a space station simulator, after all, but if for some reason you need maps that function like planets that have a breathable atmosphere and gravity that can't be turned off (see the Nukie Planet):
From e3ce289ec951ce0f9903a50a8c9a645b5f93405e Mon Sep 17 00:00:00 2001
From: Pieter-Jan Briers
Date: Thu, 4 Apr 2024 02:01:10 +0200
Subject: [PATCH 04/80] Displacement map notes
See https://github.com/space-wizards/space-station-14/pull/26709 and https://github.com/space-wizards/RobustToolbox/pull/5023
---
src/en/space-station-14/displacement-maps.md | 33 +++++++++++++++++++
src/en/specifications/robust-station-image.md | 10 ++++++
2 files changed, 43 insertions(+)
create mode 100644 src/en/space-station-14/displacement-maps.md
diff --git a/src/en/space-station-14/displacement-maps.md b/src/en/space-station-14/displacement-maps.md
new file mode 100644
index 000000000..b0a946a34
--- /dev/null
+++ b/src/en/space-station-14/displacement-maps.md
@@ -0,0 +1,33 @@
+# Displacement Maps
+
+People asked me for a quicky about how displacement maps work so uhhh...
+
+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?
+
+## Displacement map format
+
+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.
+
+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.
+
+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".
+
+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).
+
+## Actual shader
+
+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.
+
+## Displacement RSI load parameters
+
+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:
+
+```json
+"load": {
+ "srgb": false
+}
+```
+
+## Aseprite scripts
+
+I wrote some Aseprite scripts to help with authoring displacement maps. You can find them in the `Tools/` folder of SS14's repo.
diff --git a/src/en/specifications/robust-station-image.md b/src/en/specifications/robust-station-image.md
index 1f31fa925..b4da2e7da 100644
--- a/src/en/specifications/robust-station-image.md
+++ b/src/en/specifications/robust-station-image.md
@@ -17,6 +17,7 @@ Key | Meaning
`states` | A list of _states_ that store the actual meat of the RSI, see below.
`license` | Required. A valid [SPDX License Identifier](https://spdx.org/licenses/) applying to this work.
`copyright` | Required. Other arbitrary copyright info such as name, source, ...
+`load` | Special loading parameters that will change how the sprites are interpreted by the engine.
### States
@@ -93,6 +94,15 @@ Note that in practice the JSON writer probably writes the most compact JSON poss
}
```
+### Loading Parameters
+
+The `load` key allows various load parameters that change how the engine loads the sprite. Keys are as such:
+
+Key | Meaning
+--- | -------
+`srgb` | Boolean that indicates whether the sprite is interpreted as sRGB by shaders and such. Default `true`.
+
+
## Design Goals
* Editing an RSI must be possible without proper tooling. This means no binary metadata or metadata inside PNG files.
From 2a3fa41d6b9971e9d64966cf4682b6f4216c7546 Mon Sep 17 00:00:00 2001
From: Pieter-Jan Briers
Date: Thu, 4 Apr 2024 02:05:57 +0200
Subject: [PATCH 05/80] Add displacement maps to TOC
---
src/SUMMARY.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 31e75c7b4..892213d21 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -118,6 +118,7 @@ Space Station 14
- [Node Networks](en/space-station-14/node-networks.md)
- [Dungeons](en/space-station-14/dungeons.md)
- [NPCs](en/space-station-14/npcs.md)
+- [Displacement Maps](en/space-station-14/displacement-maps.md)
Design Proposals
================
From 429190120424569b793307fad834b3e660269f7b Mon Sep 17 00:00:00 2001
From: Pieter-Jan Briers
Date: Thu, 4 Apr 2024 02:28:21 +0200
Subject: [PATCH 06/80] Document new ROBUST_CVAR_ prefix
---
src/en/general-development/tips/config-file-reference.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/en/general-development/tips/config-file-reference.md b/src/en/general-development/tips/config-file-reference.md
index 6efe272cc..e60f43956 100644
--- a/src/en/general-development/tips/config-file-reference.md
+++ b/src/en/general-development/tips/config-file-reference.md
@@ -33,3 +33,4 @@ if you want to find a reference of all CVars available in the game/engine, your
* You can use the `cvar` command to view and set CVars at runtime. Note that not all CVars support changing them live: effects may include it working fine, server exploding, or nothing happening.
* You can pass `--cvar foo.bar=123` as command line argument to the client or server to override a CVar at start time. This also overrides any values set in config files.
* You can use the `ROBUST_CVARS` environment variable, which is semicolon-sepated like so: `ROBUST_CVARS=foo.bar=1234;foo.baz=hello there`. You probably don't want to accept any insecure input into this, since it's pretty basic and can't be escaped properly.
+* You can specify CVars via multiple environment variables with the `ROBUST_CVAR_` prefix (note the lack of plural from above). For example `ROBUST_CVAR_game__hostname=foobar`. A double underscore (`__`) is replaced with a `.`.
From 874c4d1709a9459d90c41bef8950a5a2d7c05aeb Mon Sep 17 00:00:00 2001
From: Pieter-Jan Briers
Date: Thu, 4 Apr 2024 02:36:19 +0200
Subject: [PATCH 07/80] Oh right explain the other two channels for
displacement maps
---
src/en/space-station-14/displacement-maps.md | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/en/space-station-14/displacement-maps.md b/src/en/space-station-14/displacement-maps.md
index b0a946a34..e12fe61a4 100644
--- a/src/en/space-station-14/displacement-maps.md
+++ b/src/en/space-station-14/displacement-maps.md
@@ -14,6 +14,10 @@ The red channel controls horizontal deviation, the green channels controls verti
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).
+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.
+
+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.
+
## Actual shader
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.
From c0e2289747842dfd87804821fb19d560a9415eac Mon Sep 17 00:00:00 2001
From: Pieter-Jan Briers
Date: Sat, 6 Apr 2024 17:19:58 +0200
Subject: [PATCH 08/80] Add Discord webhook watchdog URL example
The docs for this thing suck but it's better than nothing
---
src/en/server-hosting/setting-up-ss14-watchdog.md | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/en/server-hosting/setting-up-ss14-watchdog.md b/src/en/server-hosting/setting-up-ss14-watchdog.md
index 1dfd7039c..a2dc6049b 100644
--- a/src/en/server-hosting/setting-up-ss14-watchdog.md
+++ b/src/en/server-hosting/setting-up-ss14-watchdog.md
@@ -422,6 +422,9 @@ Serilog:
AllowedHosts: "*"
+Notification:
+ DiscordWebhook: "https://discord.com/api/webhooks/..."
+
# API URL that your watchdog is accessible from.
# This HAS to be set so the game servers can communicate with the watchdog.
# If you don't want the watchdog to be publically accessible, do `http://localhost:5000/` here.
From a0632d0108f666b19d860b35d5c2288a9cb7e42e Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Sat, 6 Apr 2024 19:13:11 +0200
Subject: [PATCH 09/80] Poweractions command docs
---
src/en/server-hosting/setting-up-redbot.md | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/src/en/server-hosting/setting-up-redbot.md b/src/en/server-hosting/setting-up-redbot.md
index 3e32dc721..825ce722a 100644
--- a/src/en/server-hosting/setting-up-redbot.md
+++ b/src/en/server-hosting/setting-up-redbot.md
@@ -52,7 +52,7 @@ If you like to have a channel where the status message is automaticly updated. T
### SS14.Watchdog Power actions
![Poweractions](../assets/images/discord/poweractions-example.png)
-Currently only has the functionality to restart servers as of writing
+Allows you to communicate with SS14.Watchdog to perform certain actions.
1. Install ```[p]cog install wizard-cogs poweractions```
2. Setup your server by running ```[p]poweractionscfg add``` and pressing the green add button. Only admins can run this command. Otherwise, the bot won't respond.
You will get a form you will be asked to fill in (**Notice**: Neither us nor the RedBot developers will receive this information. This information will only be stored by the bot and won't be shown publicly.)
@@ -63,7 +63,22 @@ You will get a form you will be asked to fill in (**Notice**: Neither us nor the
- URL: The URL to the watchdog instance, make sure to provide a URL accessible by the bot. Example: If you are exposing the watchdog's API at 'https://example.com/watchdog' then what's that you wanna input. You can probably use 'localhost' too if the bot is hosted on the same machine as the watchdog.
- Server ID: The name of your server in your watchdog's appsettings.yml that stores your server config. *Not* the "Name" config.
- API token: The ApiToken in your watchdogs configuration.
-3. After clicking submit if the bot reported success then you are done! Repeat for your other servers or give it a shot with ```[p]restartserver ```.
+3. After clicking submit if the bot reported success then you are done! Repeat for your other server.
+
+#### Commands available
+Make a server restart now:
+
+```[p]restartserver ```
+
+Restart all servers the bot has configured:
+
+```[p]restartnetwork```
+
+*This will ask for confirmation before working*
+
+Instruct the server to shutdown after the current round ends:
+
+```[p]stopserver ```
### New round pinging & Ahelp relay
While it's not specificly a bot feature, I thought I might as well throw it in here since there's no other documentation on it and it's related to Discord.
@@ -89,4 +104,4 @@ Yet to be ported to redbot. You can use a [github webhook](https://gist.github.c
```[p]cog install wizard-cogs autoresponder```
-Why... (Responds to users saying "Something when" with "When you code it", "Tetris" with "Nanotrashen Block Game" and "Based" with "Based on what". This is an inside joke inside Space Station 14 communities)
\ No newline at end of file
+Why... (Responds to users saying "Something when" with "When you code it", "Tetris" with "Nanotrashen Block Game" and "Based" with "Based on what". This is an inside joke inside Space Station 14 communities)
From 0d3c7f9cfa55973c5962d959895c86f6e807f3e5 Mon Sep 17 00:00:00 2001
From: Pieter-Jan Briers
Date: Sat, 6 Apr 2024 21:57:55 +0200
Subject: [PATCH 10/80] April 6 maintainer meeting notes
---
src/SUMMARY.md | 1 +
.../maintainer-meeting-2024-04-06.md | 131 ++++++++++++++++++
2 files changed, 132 insertions(+)
create mode 100644 src/en/maintainer-meetings/maintainer-meeting-2024-04-06.md
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 892213d21..a23c94357 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -210,6 +210,7 @@ Maintainer Meetings
==============
----------------------
+- [2024-04-06](en/maintainer-meetings/maintainer-meeting-2024-04-06.md)
- [2024-03-23](en/maintainer-meetings/maintainer-meeting-2024-03-23.md)
- [2024-02-03](en/maintainer-meetings/maintainer-meeting-2024-02-03.md)
- [2024-01-20](en/maintainer-meetings/maintainer-meeting-2024-01-20.md)
diff --git a/src/en/maintainer-meetings/maintainer-meeting-2024-04-06.md b/src/en/maintainer-meetings/maintainer-meeting-2024-04-06.md
new file mode 100644
index 000000000..146abf1db
--- /dev/null
+++ b/src/en/maintainer-meetings/maintainer-meeting-2024-04-06.md
@@ -0,0 +1,131 @@
+# Maintainer Meeting (6 April 2024)
+
+:::info
+**Time:** 6 April 2024 18:00 UTC
+
+**Attendees:**
+- Vasilis
+- Overseer (bot) (playing Wii shop music)
+- EmoGarbage
+- ElectroSR
+- PJB
+- Chief Engineer
+- Lank
+- Julian
+- ShadowCommander
+:::
+
+## Require Reviews before merging | Sloth
+> remove the dismiss review stuff from github:
+> * I check other people's reviews are done anyway
+> * adds time to pr turnaround and I gotta do a lot
+> * moony pushed for it iirc but she not here
+
+* **Can we even turn this off? If we can sure turn it off I guess**
+* Use the [userscript](https://github.com/DrSmugleaf/dismiss-all-reviews) smug made until then.
+
+## Power state networking | Sloth
+> [c#26472] how do we handle power prediction for stuff like this instead of just bandaiding it
+> * do we add a separate shared component like "SharedApcPowerReceiver" that gets networked on power changes
+> * do we just add a networked field on the component or smth
+> * also applies to batteries (powercelldraw sorta works around it)
+
+* **Yeah just make a component bool for it**
+ * **Whoever codes it gets to figure out where to put it**
+
+## Remove MapGrid TileSize | Electro
+> We should kill MapGridComponent.TileSize
+> * It would make quite a few commonly used transform & map system methods faster by not having to fetch the component
+> * I doubt its even fully supported, chances are half of the engine would explode if it were sent to something other than 1
+
+* **Removing it is probably fine**
+* **Double check with OpenDream**
+* **Whispers of wanting to move grid to content anyways, fair since it's highly SS14-specific**
+
+## Design Docs
+
+### Off-station ghots roles | Doru991
+* https://github.com/space-wizards/docs/pull/63
+
+**Opinions:**
+
+- **Verdict: barely even counts as calling it a ghost role anymore**
+- Ghost bar is neat from Goon.
+- Highly-involved off-station ghost role like the derelict station doesn't make much sense. Might as well be a different game server where people don't get an hour of investment interrupted because nukies finally blew up the station.
+
+### Shade Antagonist | UbaserB
+* https://github.com/space-wizards/docs/pull/100 💯
+* **Verdict: closed**
+* Doesn't sound like it makes much sense. Seems too reliant on roleplay and even then doesn't seem particularly enjoyable for either party. I foresee three situations in which this goes:
+ * LRP, targeted player doesn't go along with it, gets minorly annoyed by Shade until shade rage quits.
+ * LRP, targeted player does go along with it, makes full use of their antag pass (do they get an antag pass??? Are our admins going to weep??), their reward for going along with it is getting round removed
+ * MRP (even there it's a stretch), players go along with it, heavy RP, player eventually gets round removed
+* There's really nothing in it for targeted player except antag card, minor annoyance, RP opportunities and eventual round removal. Being a traitor gives you all the positive effects.
+ * Which, btw, target player NEEDS to opt into this. They can just tick traitor instead
+* For the shade itself there is too little gameplay and basically nothing to do. Too reliant on targeted player.
+* Some people suggested adapting the idea of possession to a revenant ability
+
+### Wall Worm | Ilya246
+* https://github.com/space-wizards/docs/pull/121
+* Make sure the worm is on the "side" of the wall, not inside. This limits their movement to be *along* the wall so they can't just noclip through a wall the moment anybody attacks them. Allow them to switch on airlocks and stuff I guess.
+ * Maybe make noclipping through walls an ability
+* Otherwise seems fine. Mostly just comes down to implementation and balancing details.
+
+### Cargo Postal Update | Hanzdegloker
+* https://github.com/space-wizards/docs/pull/145
+* Honestly this shouldn't be a design doc in the first place, it's too simple (couple random tat items) to really be objectionable
+* Packages should just be wrapping paper from SS13 IMO
+* Mail dropoff boxes: are there multiple across the station or is this an object at cargo? If the former, teleportation would be bad so just make it use disposals mailing.
+* Make the mail event more interesting maybe: on Delta-V cargo gets a money reward if the mail is opened by the correct recipient (ID-locked envelope, technology). Incentivizes cargo to not just steal all the mail contents themselves and actually deliver it.
+* Otherwise looks good
+
+## Current freezes
+
+## Current admin issues
+- Ahelp relay does not tell you whether the player has disconnected or not. [23716](https://github.com/space-wizards/space-station-14/issues/23716)
+- Ahelp window should tp you to the last character if the player is disconnected [20189](https://github.com/space-wizards/space-station-14/issues/20189)
+- Specific admin actions can only be performed on logged in players(e.g. Erase) [23796](https://github.com/space-wizards/space-station-14/issues/23796)
+
+## Early Access Roadmap
+- **nothing on this roadmap matters except early access trailer and admin issues.**
+- A trailer for Steam
+ - ask enrico about the trailer
+- [**game admin items**](https://github.com/space-wizards/space-station-14/issues/23246) [c#23985](https://github.com/space-wizards/space-station-14/pull/23985)
+- gamemodes/antags
+ - dynamic [c#16548](https://github.com/space-wizards/space-station-14/pull/16548)
+ - wizard (keron)
+- Steam account linking
+ - before early access
+- The game runs like shit how do people play this
+ - "IDK but maybe when I fix the watchdog you can figure it out easier" | 09/09/2023
+ - "I only played VRChat since last time and VRChat runs like shit so I don't know how people play this" | 23/09/2023
+ - "" | 21/10/2023
+ - Miros runs fine | 16/12/2023
+ - I am 5 parallel universes ahead of you
+ - We have a new Minecraft server it runs fine now (SS14 runs fine, really)
+ - Here lies Minecraft long live Satisfactory
+ - PJB is skiing
+ - It's fine :tm:
+
+Crashes / Critical bugs: (when are we moving these to GitHub)
+- Crashes the server reliably.
+- Something that bricks your client often (needs a client restart).
+ - Example: Blackscreens the client until you reconnect.
+- If something ruins the round and is disabled because of it.
+ - Example: Communal lung bug.
+- Client crash [Getting gibbed/deleted crashes your client](https://github.com/space-wizards/space-station-14/issues/26366)
+ - Immovable rod gibbing?
+
+=> till next time
+like and subscribe
+smash that button
+~~did you know only 6% of contribs join this meeting?~~ According to YouTube's statistics,
+
+## PJB personal roadmap
+- Audio rework DONE NO WAY
+- Fix infra
+- Watchdog rework: testmerges, **better way to get traces from game servers**
+- Fix perf oh god
+- PJB is reading about window scaling
+
+OwO
\ No newline at end of file
From 2b07649a5da98207e70471b5c2dda9ef632db995 Mon Sep 17 00:00:00 2001
From: faint <46868845+ficcialfaint@users.noreply.github.com>
Date: Mon, 8 Apr 2024 10:07:00 +0300
Subject: [PATCH 11/80] Update outdated template proposal path
---
src/en/general-development/feature-proposals.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/en/general-development/feature-proposals.md b/src/en/general-development/feature-proposals.md
index be571831e..cdee7ce77 100644
--- a/src/en/general-development/feature-proposals.md
+++ b/src/en/general-development/feature-proposals.md
@@ -4,7 +4,7 @@ If you are considering adding or reworking some major component of the game it's
## How do I make a proposal?
-1. Make a copy of the design proposal template located at `src/en/proposals/proposal-template.md`.
+1. Make a copy of the design proposal template located at `src/en/templates/proposal.md`.
3. Read through [SS14's Core Design Documentation](../space-station-14/core-design.md) (for gameplay-related proposals).
From 39155fb6c4220633b48a8f9d40c23ef80c69960c Mon Sep 17 00:00:00 2001
From: Hannah Giovanna Dawson
Date: Wed, 10 Apr 2024 03:33:42 +0100
Subject: [PATCH 12/80] Neutral Antag proposal: Pizza Delivery Critter (#195)
# Arnold's Pizza Needs You!
![image](https://github.com/space-wizards/docs/assets/732532/51cb9f9e-9e9c-41fe-abff-79edd8042e6e)
- Alone?
- Gullible?
- Poor?
- Unaware of our reputation?
If most/all of these apply to you, _or_ we've successfully kidnapped you
from your home, then Arnolds Pizza has a job with your name on it!
We need delivery critters willing to do one of the most difficult and
thankless tasks in known space: delivering pizzas to NanoTrasen
employees!
NanoTrasen knows we make the best pizza in the galaxy*. That's why they
have an exclusive contract with us to fulfil their Random Reward Pizza
employee satisfaciton scheme. However, NanoTrasen's boutique, black-ops
and (frequently) badly-maintained space stations are both challenging to
access and deliver to. The fell-off-a-back-of-a-van BlueSpace
teleporation devices that we use for such challenging customers are both
extremely unethical *and\* have a carry-limit small enough that we can't
send a full-sized sapient creature through with our KeepWarm pizza boxes
in tow!
That means there's a _unique_ and _exciting_ opportunity for small,
light, _expendable_ critters in our delivery services. Join today, and
we promise that we'll let you leave afterward. Just remember to get that
receipt!
*As do the Syndicate, but we don't tell them that.
---
Note that this PR makes no suggestion for what the delivery critters
should look like. The illustrative art above is just where my brainrot
took me when designing this feature.
---
.../proposals/fairlysadpanda-pizzadelivery.md | 84 +++++++++++++++++++
1 file changed, 84 insertions(+)
create mode 100644 src/en/proposals/fairlysadpanda-pizzadelivery.md
diff --git a/src/en/proposals/fairlysadpanda-pizzadelivery.md b/src/en/proposals/fairlysadpanda-pizzadelivery.md
new file mode 100644
index 000000000..2939ca94f
--- /dev/null
+++ b/src/en/proposals/fairlysadpanda-pizzadelivery.md
@@ -0,0 +1,84 @@
+# Arnold's Pizza Delivery Service
+
+| Designers | Implemented | GitHub Links |
+| -------------- | ----------- | ------------ |
+| FairlySadPanda | :x: No | TBD |
+
+# Arnold's Pizza Needs Delivery Critters
+
+- Alone?
+- Gullible?
+- Poor?
+- Unaware of our reputation?
+
+If most/all of these apply to you, _or_ we've successfully kidnapped you from your home, then Arnolds Pizza has a job with your name on it!
+
+We need delivery critters willing to do one of the most difficult and thankless tasks in known space: delivering pizzas to NanoTrasen employees!
+
+NanoTrasen knows we make the best pizza in the galaxy*. That's why they have an exclusive contract with us to fulfil their Random Reward Pizza employee satisfaciton scheme. However, NanoTrasen's boutique, black-ops and (frequently) badly-maintained space stations are both challenging to access and deliver to. The fell-off-a-back-of-a-van BlueSpace teleporation devices that we use for such challenging customers are both extremely unethical *and\* have a carry-limit small enough that we can't send a full-sized sapient creature through with our KeepWarm pizza boxes in tow!
+
+That means there's a _unique_ and _exciting_ opportunity for small, light, _expendable_ critters in our delivery services. Join today, and we promise that we'll let you leave afterward. Just remember to get that receipt!
+
+\*As do the Syndicate, but we don't tell them that.
+
+# Overview
+
+Building on positive player feedback from the April Fools Legally Distinct Space Ferret neutral antagonist, this design document outlines a role that sees the player play as a small, agile critter on a time-limited mission to complete a delivery task to a member of the crew. Success is delivery and retreival of a signed receipt: failure is a tragic death due to the compromising of the nuclear fission heater that the delivery company has strapped to said critter's back.
+
+## Player Profiles
+
+- **Pop-In** wants to pop-in to to the round for a few minutes and interact with the crew, but doesn't have time to stick around for the evac shuttle.
+- **Cutesy Gamer** wants to play as a cute critter with more than just roleplaying to do.
+- **Comedy Gamer** wants to be placed in a tense, absurd situation where their game knowledge can shine to get a challenging goal done.
+
+## How it works
+
+- A mid-round ghost role of "Pizza Delivery critter" allows a player to spawn as a cute sapient critter similar to a monkey or kobold at appropriate spawns decided by the map creator, or by mimicing vent critter spawning should this retrofitting have not taken place.
+- This critter is given two sets of information:
+ 1. The identity of its delivery target, including their face, profession and name.
+ 2. The amount of time they have to complete the delivery before the KeepWarm heater on their back violently explodes.
+- The timer is constantly displayed at the bottom of the screen, above the equipment bar. This is a reference, appropriately enough, to _Pizza Tower_.
+- The critter is a neutral antagonist with one objective:
+ - Get a signed reciept from the target before time runs out.
+- The critter's target must be alive and not in crit to be chosen.
+ - If the target is gibbed or becomes SSD for any reason during the delivery attempt, Arnold's Pizza declares the order void and the player is freed from the timer. If this happens, they get to eat the pizza. This is the "neutral" end condition for this antag - the player will not greentext, but they do not get round-removed.
+- The critter the player plays at has the following abilities:
+ - Small creature hitboxes, allowing it to slide underneath most doors. Arnold's Pizza has extensive experience dealing with NT stations and has engineered its delivery critters to be able to actually have a chance of delivering to Urist McScientist who is sitting behind three secure airlocks.
+ - The following item slots:
+ - Hat (containing a branded red Arnold's Pizza cap that itself contains a tiny item storage slot, containing a pen)
+ - Mask
+ - Belt (containing a branded o2 canister)
+ - Pocket (with a branded gas mask)
+ - PDA/ID Card
+ - One hand slot
+ - The critter is not especially vulnerable to any damage type, breathes oxygen, but has no capacity at all to wear a spacesuit. They are provided with the means to survive atmos failure, though, preventing frustrating spawns.
+ in the event the station is spaced, but they will die to barotrauma somewhat quickly.
+ - The critter has the same amount of health as a monkey.
+ - The critter nyooms - that is, they have a higher-than-average base and running speed, appropriate for a frantic delivery vehicle.
+ - The critter only speaks in cute noises unless given cognizine.
+- The critter has the ability to print out a receipt for its order. This receipt contains the same information the critter was given regarding the target's identity.
+- The receipt has a space for a signature. The only way this signature can be filled in is by the target. It needs to be filled in by using a pen (of any kind) on the receipt.
+- The receipt must be handed back to the critter, who then must feed it back into the heater to retrieve the pizza. This counts as a victory and allows the critter to greentext.
+- The pizza is one of Arnold's specials. The pizza will have one of the following properties:
+ - Dank: contains, as you'd expect, dankness, and gives the user hallucinations (cannabis).
+ - Healthy: like the current Arnold's pizza item, this contains a powerful healing agent (omnizine).
+ - Stimulants: this pizza is loaded with sugar and makes the target nyoom for a medium period.
+ - Hot N Spicy: eating the pizza causes the target to set on fire.
+ - Space Carp Pizza allows the target to avoid pressure damage for a medium period.
+ - Classic: (PRE WOUND MED) causes the target to detonate. (POST WOUND MED) causes the target's limbs to fly off.
+ - All of these pizzas have a "paper-oni" pizza variant for moths to eat.
+- The pizza types have clear labels on their boxes and unique descriptions, but do not overtly say what they do. The positive-effect pizzas are weighted more likely to appear than the negative ones, with the Classic pizza being a rare chance.
+- If the critter fails to deliver the pizza in the time limit, it explodes. This explosion is faked - it gibs the critter but convers no damage to anyone else standing nearby, even on the same tile, to prevent this feature being abused to suicide bomb people.
+- It is possible for a member of the crew with bomb disposal knowledge to disable the KeepWarm heater, thus saving the critter's life. If this occurs, the critter cannot greentext.
+- If the target is in crit or cuffed, using the printed receipt on them whilst the critter has a pen in their pocket allows the critter to forge the signature, greentexting.
+- If the critter has delivered its pizza, it can become eligible to deliver another pizza again later in the round provided the pizza delivery event is rolled again (or if an admin is feeling cruel).
+- The critter always has the option of aborting the mission and teleporting back off the station, to avoid feel-bad moments where the objective is undeliverable, the station is in too bad a state to attempt a delivery, etc.
+
+## Traitor/Nukeops Gameplay
+
+- The Syndicate also have an exclusive contract with Arnold's Pizza, and they leverage that to do a little trolling and help themselves out.
+- A traitor or nukie can order a pizza delivery for themselves or a member of NanoTrasen crew. If they do this, they can specify what exactly the critter is going to deliver. This includes a new, exciting flavour: a bomb with a fuse that looks like it fell out of a Looney Tunes cartoon. The bomb is much too heavy for the critter to hold, and they drop it immediately.
+- This bomb detonates a few seconds after the critter has retrieved it from its KeepWarm heater, doing moderate damage to the station in the process.
+ - This is a reference both to Looney Tunes and the famous "sometimes you just can't get rid of a bomb" sketch from the Adam West Batman TV series.
+- The critter is not told they are delivering a bomb or that they're working for the Syndicate, and there's no metagameable way to know if a pizza delivery is legitimate or a trap.
+- This mechanic makes sure that there's a theoretical reason that a player may refuse a delivery.
From bfc44d91f6eb027682c6f7eadbfeb055d2deeaec Mon Sep 17 00:00:00 2001
From: Hannah Giovanna Dawson
Date: Wed, 10 Apr 2024 16:11:34 +0100
Subject: [PATCH 13/80] Add link to Pizza Delivery Critter in SUMMARY.md (#197)
Forgot to add this and it was merged last night
without someone doing it... oops
---
src/SUMMARY.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index a23c94357..dd6ed9bd2 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -144,6 +144,7 @@ Design Proposals
- [Turf War](en/proposals/deltanedas-turf-war.md)
- [Signaller Rework](en/proposals/deltanedas-signaller-rework.md)
- [Thief antagonist](en/proposals/theshued-thief.md)
+- [Pizza Delivery Critter](en/proposals/fairlysadpanda-pizzadelivery.md)
Server Hosting
==============
From 8860e36ff9f28af6280231ff291efc4f9197a313 Mon Sep 17 00:00:00 2001
From: Brandon Hu <103440971+Brandon-Huu@users.noreply.github.com>
Date: Thu, 11 Apr 2024 00:43:55 +0000
Subject: [PATCH 14/80] fix: Updated the path for template proposals (#196)
Fixes the path on
https://docs.spacestation14.com/en/general-development/feature-proposals.html
![image](https://github.com/space-wizards/docs/assets/103440971/2456cb48-3da8-4235-8ad2-376f34129ae8)
https://github.com/space-wizards/docs/commit/f1fcbeecfd108ed16a1b5154db54e9cea5d5aeff
https://github.com/space-wizards/docs/commit/4d870eca71b963174199eda622b90aedb14332df
https://github.com/space-wizards/docs/commit/e12e6cdf9d8743de8b83fdd1a984ca40183ca1d4
From 639397b0aef5ec28719b314b2ed19462255cee28 Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Sun, 14 Apr 2024 00:30:33 +0200
Subject: [PATCH 15/80] Port maintainer list from mdbook to the wiki (#200)
https://hackmd.io/7mwrXfpHTWmXcS2tE1_uSA
Had made this when someone said they needed a list for seeing names from
GitHub to discord and I thought it should probably be more reachable so
here it is!
---
src/SUMMARY.md | 1 +
.../space-wizards-maintainer-list.md | 43 +++++++++++++++++++
2 files changed, 44 insertions(+)
create mode 100644 src/en/community/space-wizards-maintainer-list.md
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index dd6ed9bd2..682fbcb32 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -191,6 +191,7 @@ Community
- [Grafana Dashboards](en/community/infrastructure-reference/grafana-dashboards.md)
- [Space Wizards Hub Rules](en/community/space-wizards-hub-rules.md)
- [Space Wizards Role Hierarchy](en/community/space-wizards-role-hierarchy.md)
+- [Space Wizards Maintainer List](en/community/space-wizards-maintainer-list.md)
- [Discord Rich Presence Repository](en/community/discord-rich-presence-repository.md)
- [Admin](en/community/admin.md)
- [Admin Tooling](en/community/admin/admin-tooling.md)
diff --git a/src/en/community/space-wizards-maintainer-list.md b/src/en/community/space-wizards-maintainer-list.md
new file mode 100644
index 000000000..9be18c796
--- /dev/null
+++ b/src/en/community/space-wizards-maintainer-list.md
@@ -0,0 +1,43 @@
+# Space Wizard Maintainer List
+This document shows all current Maintainers on the project. Along with their GitHub and Discord contacts.
+
+I will do my best to keep this up to date as Maintainers come and leave.
+
+The format is as follows
+
+**Github - Discord (ID)**
+
+Both Engine and Content Maintainers:
+- [Jezithyr](https://github.com/Jezithyr) - @jezithyr (107689319396831232)
+- [ZoldorfTheWizard](https://github.com/ZoldorfTheWizard) - @zoldorf (140921734109855744)
+- [PJB3005](https://github.com/PJB3005) - @pjb (97089048065097728)
+- [ShadowCommander](https://github.com/ShadowCommander) - @shadowcommander (104693014407950336)
+- [DrSmugleaf](https://github.com/DrSmugleaf) - @drsmugleaf (109067752286715904)
+- [mirrorcult](https://github.com/mirrorcult) - @mirrorcult (176065747200507904)
+- [metalgearsloth](https://github.com/metalgearsloth) - @metalgearsloth (229052932476108800)
+- [Visne](https://github.com/Visne) - @visne (182723474257608705)
+- [keronshb](https://github.com/keronshb) - @keronshb (226429200553213952)
+- [AJCM-git](https://github.com/AJCM-git) - @ajcm_git (239467362380808192)
+- [ElectroJr](https://github.com/ElectroJr) - @electrosr (348118974497816577)
+- [vulppine](https://github.com/vulppine) - @vulppine (102244617314914304)
+
+Content Maintainers:
+- [Partmedia](https://github.com/Partmedia) - @notafet (774744999379599360)
+- [Emisse](https://github.com/Emisse) - @emisse (109430489684705280)
+- [Chief-Engineer](https://github.com/Chief-Engineer) - @am.ghost (267392122179682307)
+
+Junior Maintainers:
+- [Tayrtahn](https://github.com/Tayrtahn) - @tayrtahn (147050540214386689)
+- [deathride58](https://github.com/deathride58) - @bhijn (77867936647225344)
+- [VasilisThePikachu](https://github.com/VasilisThePikachu) - @vasilisiscool (322708417540259841)
+- [Slava0135](https://github.com/Slava0135) - @slava0135 (439814569972727818)
+- [ficcialfaint](https://github.com/ficcialfaint) - @ficcialfaint (481532274211422209)
+- [chromiumboy](https://github.com/chromiumboy) - @chromiumboy (395222876753625088)
+- [TemporalOroboros](https://github.com/TemporalOroboros) - @the_quiet_one (423542163503185942)
+- [Flareguy](https://github.com/Flareguy) - @flar3guy (310216766192091156)
+- [TheShuEd](https://github.com/TheShuEd) - @eshhhed (267327466060775425)
+- [EmoGarbage404](https://github.com/EmoGarbage404) - @emogarbage (500128901805244436)
+- [LankLTE](https://github.com/LankLTE) - @lanklte (328292818265047041)
+
+Engine maintainers:
+No one maintains only engine :p
From 806ce8c82321543e34c3c64eaf15b809e95313f5 Mon Sep 17 00:00:00 2001
From: Pieter-Jan Briers
Date: Thu, 18 Apr 2024 23:02:34 +0200
Subject: [PATCH 16/80] Update Grafana dashboards
I mean we have more but at least let's update these
---
.../grafana-dashboards.md | 6617 ++++++++++++-----
1 file changed, 4621 insertions(+), 1996 deletions(-)
diff --git a/src/en/community/infrastructure-reference/grafana-dashboards.md b/src/en/community/infrastructure-reference/grafana-dashboards.md
index 5640725ad..8efd3ad89 100644
--- a/src/en/community/infrastructure-reference/grafana-dashboards.md
+++ b/src/en/community/infrastructure-reference/grafana-dashboards.md
@@ -5,11 +5,229 @@ Contains the export for our Grafana dashboards at the time of writing. You will
## Game Servers
```json
{
+ "__inputs": [
+ {
+ "name": "DS_PROMETHEUS",
+ "label": "Prometheus",
+ "description": "",
+ "type": "datasource",
+ "pluginId": "prometheus",
+ "pluginName": "Prometheus"
+ },
+ {
+ "name": "DS_SS14_POSTGRESQL",
+ "label": "SS14 PostgreSQL",
+ "description": "",
+ "type": "datasource",
+ "pluginId": "grafana-postgresql-datasource",
+ "pluginName": "PostgreSQL"
+ }
+ ],
+ "__elements": {
+ "ee25b1d7-c005-4e4d-965c-466296dc64db": {
+ "name": "Connections",
+ "uid": "ee25b1d7-c005-4e4d-965c-466296dc64db",
+ "kind": 1,
+ "model": {
+ "datasource": {
+ "type": "grafana-postgresql-datasource",
+ "uid": "${DS_SS14_POSTGRESQL}"
+ },
+ "description": "",
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": -1,
+ "drawStyle": "bars",
+ "fillOpacity": 100,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "linearThreshold": 10,
+ "log": 2,
+ "type": "symlog"
+ },
+ "showPoints": "auto",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green",
+ "value": null
+ }
+ ]
+ }
+ },
+ "overrides": []
+ },
+ "options": {
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": true
+ },
+ "tooltip": {
+ "mode": "single",
+ "sort": "none"
+ }
+ },
+ "targets": [
+ {
+ "datasource": {
+ "type": "postgres",
+ "uid": "ol4_imoGk"
+ },
+ "editorMode": "code",
+ "format": "time_series",
+ "rawQuery": true,
+ "rawSql": "SELECT\r\n \"time\",\r\n 1 as \"Connection\"\r\nFROM\r\n connection_log\r\nWHERE\r\n $__timeFilter(\"time\")\r\nGROUP BY\r\n 1",
+ "refId": "Connection",
+ "sql": {
+ "columns": [
+ {
+ "parameters": [
+ {
+ "name": "\"time\"",
+ "type": "functionParameter"
+ }
+ ],
+ "type": "function"
+ },
+ {
+ "parameters": [],
+ "type": "function"
+ }
+ ],
+ "groupBy": [
+ {
+ "property": {
+ "type": "string"
+ },
+ "type": "groupBy"
+ }
+ ],
+ "limit": 50,
+ "whereJsonTree": {
+ "children1": [
+ {
+ "id": "b89a99a9-89ab-4cde-b012-3189809a91fc",
+ "properties": {
+ "field": "\"time\"",
+ "operator": "equal",
+ "value": [
+ null
+ ],
+ "valueSrc": [
+ "value"
+ ],
+ "valueType": [
+ "datetime"
+ ]
+ },
+ "type": "rule"
+ }
+ ],
+ "id": "a989bbb9-89ab-4cde-b012-318980999ce7",
+ "type": "group"
+ }
+ },
+ "table": "connection_log"
+ },
+ {
+ "datasource": {
+ "name": "Expression",
+ "type": "__expr__",
+ "uid": "__expr__"
+ },
+ "downsampler": "sum",
+ "expression": "Connection",
+ "hide": false,
+ "refId": "Connections",
+ "type": "resample",
+ "upsampler": "fillna",
+ "window": "5m"
+ }
+ ],
+ "title": "Connections",
+ "transformations": [
+ {
+ "id": "filterByRefId",
+ "options": {
+ "include": "Connections"
+ }
+ }
+ ],
+ "type": "timeseries"
+ }
+ }
+ },
+ "__requires": [
+ {
+ "type": "grafana",
+ "id": "grafana",
+ "name": "Grafana",
+ "version": "10.4.2"
+ },
+ {
+ "type": "datasource",
+ "id": "grafana-postgresql-datasource",
+ "name": "PostgreSQL",
+ "version": "1.0.0"
+ },
+ {
+ "type": "datasource",
+ "id": "prometheus",
+ "name": "Prometheus",
+ "version": "1.0.0"
+ },
+ {
+ "type": "panel",
+ "id": "stat",
+ "name": "Stat",
+ "version": ""
+ },
+ {
+ "type": "panel",
+ "id": "timeseries",
+ "name": "Time series",
+ "version": ""
+ }
+ ],
"annotations": {
"list": [
{
"builtIn": 1,
- "datasource": "-- Grafana --",
+ "datasource": {
+ "type": "datasource",
+ "uid": "grafana"
+ },
"enable": true,
"hide": true,
"iconColor": "rgba(0, 211, 255, 1)",
@@ -27,148 +245,243 @@ Contains the export for our Grafana dashboards at the time of writing. You will
"editable": true,
"fiscalYearStartMonth": 0,
"graphTooltip": 0,
- "id": 1,
+ "id": null,
"links": [],
"liveNow": false,
"panels": [
{
- "aliasColors": {
- "wizards_den_eu_west": "blue"
+ "gridPos": {
+ "h": 5,
+ "w": 24,
+ "x": 0,
+ "y": 0
+ },
+ "id": 27,
+ "libraryPanel": {
+ "uid": "ee25b1d7-c005-4e4d-965c-466296dc64db",
+ "name": "Connections"
+ }
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
},
- "bars": false,
- "dashLength": 10,
- "dashes": false,
"fieldConfig": {
"defaults": {
- "links": []
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 30,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "stepAfter",
+ "lineWidth": 2,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "decimals": 0,
+ "links": [],
+ "mappings": [],
+ "min": 0,
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green",
+ "value": null
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ },
+ "unit": "short"
},
- "overrides": []
+ "overrides": [
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "wizards_den_eu_west"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "blue",
+ "mode": "fixed"
+ }
+ }
+ ]
+ }
+ ]
},
- "fill": 3,
- "fillGradient": 0,
"gridPos": {
"h": 7,
- "w": 10,
+ "w": 12,
"x": 0,
- "y": 0
+ "y": 5
},
- "hiddenSeries": false,
"id": 2,
- "legend": {
- "avg": false,
- "current": false,
- "max": false,
- "min": false,
- "rightSide": false,
- "show": true,
- "total": false,
- "values": false
- },
- "lines": true,
- "linewidth": 2,
- "nullPointMode": "null",
"options": {
- "alertThreshold": true
- },
- "percentage": false,
- "pluginVersion": "8.3.2",
- "pointradius": 2,
- "points": false,
- "renderer": "flot",
- "seriesOverrides": [],
- "spaceLength": 10,
- "stack": false,
- "steppedLine": true,
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": true
+ },
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
+ }
+ },
+ "pluginVersion": "10.2.3",
"targets": [
{
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
"expr": "robust_player_count",
"interval": "",
- "legendFormat": "{{job}}",
+ "legendFormat": "{{server}}",
"refId": "A"
}
],
- "thresholds": [],
- "timeRegions": [],
"title": "Player Count",
- "tooltip": {
- "shared": true,
- "sort": 0,
- "value_type": "individual"
- },
- "type": "graph",
- "xaxis": {
- "mode": "time",
- "show": true,
- "values": []
- },
- "yaxes": [
- {
- "decimals": 0,
- "format": "short",
- "logBase": 1,
- "min": "0",
- "show": true
- },
- {
- "format": "short",
- "logBase": 1,
- "show": true
- }
- ],
- "yaxis": {
- "align": false
- }
+ "type": "timeseries"
},
{
- "aliasColors": {
- "wizards_den_eu_west": "blue"
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
},
- "bars": false,
- "dashLength": 10,
- "dashes": false,
"fieldConfig": {
"defaults": {
- "links": []
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 30,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "stepAfter",
+ "lineWidth": 2,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "decimals": 0,
+ "links": [],
+ "mappings": [],
+ "min": 0,
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green",
+ "value": null
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ },
+ "unit": "short"
},
- "overrides": []
+ "overrides": [
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "wizards_den_eu_west"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "blue",
+ "mode": "fixed"
+ }
+ }
+ ]
+ }
+ ]
},
- "fill": 3,
- "fillGradient": 0,
"gridPos": {
"h": 7,
- "w": 10,
- "x": 10,
- "y": 0
+ "w": 12,
+ "x": 12,
+ "y": 5
},
- "hiddenSeries": false,
"id": 23,
- "legend": {
- "avg": false,
- "current": false,
- "max": false,
- "min": false,
- "rightSide": false,
- "show": true,
- "total": false,
- "values": false
- },
- "lines": true,
- "linewidth": 2,
- "nullPointMode": "null",
"options": {
- "alertThreshold": true
- },
- "percentage": false,
- "pluginVersion": "8.3.2",
- "pointradius": 2,
- "points": false,
- "renderer": "flot",
- "seriesOverrides": [],
- "spaceLength": 10,
- "stack": false,
- "steppedLine": true,
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": false
+ },
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
+ }
+ },
+ "pluginVersion": "10.2.3",
"targets": [
{
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
"exemplar": true,
"expr": "sum(robust_player_count)",
"interval": "",
@@ -176,37 +489,8 @@ Contains the export for our Grafana dashboards at the time of writing. You will
"refId": "A"
}
],
- "thresholds": [],
- "timeRegions": [],
"title": "Total Player Count",
- "tooltip": {
- "shared": true,
- "sort": 0,
- "value_type": "individual"
- },
- "type": "graph",
- "xaxis": {
- "mode": "time",
- "show": true,
- "values": []
- },
- "yaxes": [
- {
- "decimals": 0,
- "format": "short",
- "logBase": 1,
- "min": "0",
- "show": true
- },
- {
- "format": "short",
- "logBase": 1,
- "show": true
- }
- ],
- "yaxis": {
- "align": false
- }
+ "type": "timeseries"
},
{
"alert": {
@@ -215,9 +499,10 @@ Contains the export for our Grafana dashboards at the time of writing. You will
{
"evaluator": {
"params": [
+ 1,
28
],
- "type": "lt"
+ "type": "within_range"
},
"operator": {
"type": "and"
@@ -248,462 +533,466 @@ Contains the export for our Grafana dashboards at the time of writing. You will
}
]
},
- "aliasColors": {
- "PlayerCount wizards_den_us_west": "dark-orange",
- "wizards_den_eu_west": "blue"
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
},
- "bars": false,
- "dashLength": 10,
- "dashes": false,
"fieldConfig": {
"defaults": {
- "links": []
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 10,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 2,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "line+area"
+ }
+ },
+ "links": [],
+ "mappings": [],
+ "max": 35,
+ "min": 0,
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "transparent",
+ "value": null
+ },
+ {
+ "color": "red",
+ "value": 1
+ },
+ {
+ "color": "transparent",
+ "value": 28
+ }
+ ]
+ },
+ "unit": "hertz"
},
- "overrides": []
+ "overrides": [
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "PlayerCount wizards_den_us_west"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "dark-orange",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "wizards_den_eu_west"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "blue",
+ "mode": "fixed"
+ }
+ }
+ ]
+ }
+ ]
},
- "fill": 1,
- "fillGradient": 0,
"gridPos": {
"h": 6,
- "w": 10,
+ "w": 12,
"x": 0,
- "y": 7
+ "y": 12
},
- "hiddenSeries": false,
"id": 4,
- "legend": {
- "alignAsTable": false,
- "avg": false,
- "current": false,
- "max": false,
- "min": false,
- "rightSide": false,
- "show": true,
- "total": false,
- "values": false
- },
- "lines": true,
- "linewidth": 2,
- "nullPointMode": "null",
"options": {
- "alertThreshold": true
- },
- "percentage": false,
- "pluginVersion": "8.3.2",
- "pointradius": 2,
- "points": false,
- "renderer": "flot",
- "seriesOverrides": [],
- "spaceLength": 10,
- "stack": false,
- "steppedLine": false,
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": true
+ },
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
+ }
+ },
+ "pluginVersion": "10.2.3",
"targets": [
{
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
"expr": "rate(robust_server_curtick[30s])",
"interval": "",
- "legendFormat": "{{job}}",
+ "legendFormat": "{{server}}",
"refId": "A"
}
],
- "thresholds": [
- {
- "colorMode": "critical",
- "fill": true,
- "line": true,
- "op": "lt",
- "value": 28,
- "visible": true
- }
- ],
- "timeRegions": [],
"title": "TPS",
- "tooltip": {
- "shared": true,
- "sort": 0,
- "value_type": "individual"
- },
- "type": "graph",
- "xaxis": {
- "mode": "time",
- "show": true,
- "values": []
- },
- "yaxes": [
- {
- "format": "hertz",
- "logBase": 1,
- "max": "35",
- "min": "0",
- "show": true
- },
- {
- "decimals": 0,
- "format": "short",
- "logBase": 1,
- "show": false
- }
- ],
- "yaxis": {
- "align": false
- }
+ "type": "timeseries"
},
{
- "aliasColors": {},
- "bars": false,
- "dashLength": 10,
- "dashes": false,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "description": "Current round length",
"fieldConfig": {
"defaults": {
- "links": []
+ "color": {
+ "mode": "thresholds"
+ },
+ "mappings": [],
+ "min": 0,
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "blue",
+ "value": null
+ },
+ {
+ "color": "green",
+ "value": 1
+ },
+ {
+ "color": "yellow",
+ "value": 7200
+ },
+ {
+ "color": "orange",
+ "value": 9000
+ },
+ {
+ "color": "red",
+ "value": 10800
+ }
+ ]
+ },
+ "unit": "dthms"
},
"overrides": []
},
- "fill": 1,
- "fillGradient": 0,
"gridPos": {
- "h": 6,
- "w": 10,
- "x": 10,
- "y": 7
- },
- "hiddenSeries": false,
- "id": 12,
- "legend": {
- "avg": false,
- "current": false,
- "max": false,
- "min": false,
- "show": true,
- "total": false,
- "values": false
+ "h": 24,
+ "w": 2,
+ "x": 12,
+ "y": 12
},
- "lines": true,
- "linewidth": 1,
- "nullPointMode": "null",
+ "id": 28,
"options": {
- "alertThreshold": true
- },
- "percentage": false,
- "pluginVersion": "8.3.2",
- "pointradius": 2,
- "points": false,
- "renderer": "flot",
- "seriesOverrides": [],
- "spaceLength": 10,
- "stack": false,
- "steppedLine": false,
- "targets": [
- {
- "expr": "rate(process_cpu_seconds_total[10s])",
- "interval": "",
- "legendFormat": "{{job}}",
- "refId": "A"
- }
- ],
- "thresholds": [],
- "timeRegions": [],
- "title": "CPU Usage",
- "tooltip": {
- "shared": true,
- "sort": 0,
- "value_type": "individual"
- },
- "type": "graph",
- "xaxis": {
- "mode": "time",
- "show": true,
- "values": []
- },
- "yaxes": [
- {
- "decimals": 1,
- "format": "percentunit",
- "logBase": 1,
- "max": "1",
- "min": "0",
- "show": true
+ "colorMode": "value",
+ "graphMode": "none",
+ "justifyMode": "center",
+ "orientation": "horizontal",
+ "reduceOptions": {
+ "calcs": [
+ "lastNotNull"
+ ],
+ "fields": "",
+ "values": false
},
- {
- "format": "short",
- "logBase": 1,
- "show": false
- }
- ],
- "yaxis": {
- "align": false
- }
- },
- {
- "alert": {
- "alertRuleTags": {},
- "conditions": [
- {
- "evaluator": {
- "params": [
- 520850446
- ],
- "type": "gt"
- },
- "operator": {
- "type": "and"
- },
- "query": {
- "params": [
- "A",
- "1m",
- "now"
- ]
- },
- "reducer": {
- "params": [],
- "type": "max"
- },
- "type": "query"
- }
- ],
- "executionErrorState": "alerting",
- "for": "5m",
- "frequency": "1m",
- "handler": 1,
- "message": "Memory Usage Alert",
- "name": "Managed Memory alert",
- "noDataState": "no_data",
- "notifications": [
- {
- "uid": "N5nihcmMk"
- }
- ]
- },
- "aliasColors": {
- "wizards_den_eu_west": "blue"
- },
- "bars": false,
- "dashLength": 10,
- "dashes": false,
- "fieldConfig": {
- "defaults": {
- "links": []
+ "showPercentChange": false,
+ "text": {
+ "valueSize": 40
},
- "overrides": []
- },
- "fill": 1,
- "fillGradient": 0,
- "gridPos": {
- "h": 6,
- "w": 10,
- "x": 0,
- "y": 13
+ "textMode": "value",
+ "wideLayout": true
},
- "hiddenSeries": false,
- "id": 9,
- "legend": {
- "avg": false,
- "current": false,
- "max": false,
- "min": false,
- "show": true,
- "total": false,
- "values": false
- },
- "lines": true,
- "linewidth": 1,
- "nullPointMode": "null",
- "options": {
- "alertThreshold": true
- },
- "percentage": false,
- "pluginVersion": "8.3.2",
- "pointradius": 2,
- "points": false,
- "renderer": "flot",
- "seriesOverrides": [],
- "spaceLength": 10,
- "stack": false,
- "steppedLine": false,
+ "pluginVersion": "10.4.2",
"targets": [
{
- "expr": "dotnet_total_memory_bytes",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "exemplar": false,
+ "expr": "ss14_round_length{job=\"gameservers\"}",
"format": "time_series",
+ "instant": true,
"interval": "",
- "legendFormat": "{{job}}",
+ "legendFormat": "{{server}}",
+ "range": false,
"refId": "A"
}
],
- "thresholds": [
- {
- "colorMode": "critical",
- "fill": true,
- "line": true,
- "op": "gt",
- "value": 520850446,
- "visible": true
- }
- ],
- "timeRegions": [],
- "title": "Managed Memory",
- "tooltip": {
- "shared": true,
- "sort": 0,
- "value_type": "individual"
- },
- "type": "graph",
- "xaxis": {
- "mode": "time",
- "show": true,
- "values": []
- },
- "yaxes": [
- {
- "$$hashKey": "object:560",
- "format": "bytes",
- "logBase": 1,
- "min": "0",
- "show": true
- },
- {
- "$$hashKey": "object:561",
- "format": "short",
- "logBase": 1,
- "show": true
- }
- ],
- "yaxis": {
- "align": false
- }
+ "title": "Current round length",
+ "type": "stat"
},
{
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
"description": "",
"fieldConfig": {
"defaults": {
+ "color": {
+ "mode": "thresholds"
+ },
"mappings": [],
+ "min": 0,
"thresholds": {
"mode": "absolute",
"steps": [
{
- "color": "green",
+ "color": "red",
"value": null
+ },
+ {
+ "color": "orange",
+ "value": 5
+ },
+ {
+ "color": "#EAB839",
+ "value": 15
+ },
+ {
+ "color": "green",
+ "value": 25
+ },
+ {
+ "color": "green",
+ "value": 60
+ },
+ {
+ "color": "blue",
+ "value": 70
}
]
- },
- "unit": "dthms"
+ }
},
"overrides": []
},
"gridPos": {
- "h": 3,
- "w": 5,
- "x": 10,
- "y": 13
+ "h": 24,
+ "w": 8,
+ "x": 14,
+ "y": 12
},
- "id": 6,
+ "id": 15,
"options": {
"colorMode": "value",
- "graphMode": "none",
- "justifyMode": "auto",
- "orientation": "auto",
+ "graphMode": "area",
+ "justifyMode": "center",
+ "orientation": "horizontal",
"reduceOptions": {
"calcs": [
- "last"
+ "lastNotNull"
],
"fields": "",
"values": false
},
+ "showPercentChange": false,
"text": {},
- "textMode": "auto"
+ "textMode": "auto",
+ "wideLayout": true
},
- "pluginVersion": "8.3.2",
+ "pluginVersion": "10.4.2",
"targets": [
{
- "exemplar": true,
- "expr": "ss14_round_length{job=\"wizards_den_lizard\"}",
- "instant": true,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "builder",
+ "exemplar": false,
+ "expr": "robust_player_count",
+ "format": "time_series",
+ "instant": false,
"interval": "",
- "legendFormat": "",
+ "legendFormat": "{{server}}",
+ "range": true,
"refId": "A"
}
],
- "title": "US West Round Duration",
+ "title": "Player counts",
"type": "stat"
},
{
- "description": "US west playercount",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "description": "Average round length over the selected range",
"fieldConfig": {
"defaults": {
"color": {
"mode": "thresholds"
},
- "displayName": "Players",
"mappings": [],
+ "min": 0,
"thresholds": {
"mode": "absolute",
"steps": [
{
- "color": "green",
+ "color": "red",
"value": null
+ },
+ {
+ "color": "orange",
+ "value": 1800
+ },
+ {
+ "color": "#EAB839",
+ "value": 2700
+ },
+ {
+ "color": "green",
+ "value": 3600
+ },
+ {
+ "color": "green",
+ "value": 5400
+ },
+ {
+ "color": "yellow",
+ "value": 7200
+ },
+ {
+ "color": "orange",
+ "value": 9000
+ },
+ {
+ "color": "red",
+ "value": 10800
}
]
},
- "unit": "none"
+ "unit": "dthms"
},
"overrides": []
},
"gridPos": {
- "h": 3,
+ "h": 24,
"w": 2,
- "x": 15,
- "y": 13
+ "x": 22,
+ "y": 12
},
- "id": 15,
- "links": [],
+ "id": 24,
"options": {
"colorMode": "value",
"graphMode": "none",
"justifyMode": "center",
- "orientation": "auto",
+ "orientation": "horizontal",
"reduceOptions": {
"calcs": [
- "last"
+ "lastNotNull"
],
"fields": "",
"values": false
},
- "text": {},
- "textMode": "auto"
+ "showPercentChange": false,
+ "text": {
+ "valueSize": 40
+ },
+ "textMode": "value",
+ "wideLayout": true
},
- "pluginVersion": "8.3.2",
+ "pluginVersion": "10.4.2",
"targets": [
{
- "expr": "robust_player_count",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "exemplar": false,
+ "expr": "$__range_s / increase(ss14_round_number[$__range])",
"format": "time_series",
"instant": true,
"interval": "",
- "legendFormat": "{{job}}",
+ "legendFormat": "{{server}}",
+ "range": false,
"refId": "A"
}
],
- "title": "USW",
- "transformations": [
- {
- "id": "filterFieldsByName",
- "options": {
- "include": {
- "names": [
- "Time",
- "wizards_den_lizard"
- ]
- }
- }
- }
- ],
+ "title": "Average round length",
"type": "stat"
},
{
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
"fieldConfig": {
"defaults": {
"color": {
- "mode": "thresholds"
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 10,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
},
+ "decimals": 1,
+ "links": [],
"mappings": [],
+ "max": 1,
+ "min": 0,
"thresholds": {
"mode": "absolute",
"steps": [
@@ -716,106 +1005,1647 @@ Contains the export for our Grafana dashboards at the time of writing. You will
"value": 80
}
]
- }
+ },
+ "unit": "percentunit"
},
"overrides": []
},
"gridPos": {
- "h": 3,
- "w": 2,
- "x": 18,
- "y": 13
+ "h": 6,
+ "w": 12,
+ "x": 0,
+ "y": 18
},
- "id": 25,
+ "id": 12,
"options": {
- "colorMode": "value",
- "graphMode": "area",
- "justifyMode": "auto",
- "orientation": "auto",
- "reduceOptions": {
- "calcs": [
- "lastNotNull"
- ],
- "fields": "",
- "values": false
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": true
},
- "text": {},
- "textMode": "auto"
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
+ }
},
- "pluginVersion": "8.3.2",
+ "pluginVersion": "10.2.3",
"targets": [
{
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
"exemplar": true,
- "expr": "sum(robust_player_count)",
+ "expr": "rate(process_cpu_seconds_total[$__rate_interval])",
"interval": "",
- "legendFormat": "",
+ "legendFormat": "{{server}}",
+ "range": true,
"refId": "A"
}
],
- "title": "Total Players",
- "type": "stat"
+ "title": "CPU Usage",
+ "type": "timeseries"
},
{
- "description": "",
- "fieldConfig": {
- "defaults": {
- "mappings": [],
- "thresholds": {
- "mode": "absolute",
- "steps": [
- {
- "color": "green",
- "value": null
- }
- ]
- },
- "unit": "dthms"
- },
- "overrides": []
- },
- "gridPos": {
- "h": 3,
- "w": 5,
- "x": 10,
- "y": 16
- },
- "id": 7,
- "options": {
- "colorMode": "value",
- "graphMode": "none",
- "justifyMode": "auto",
- "orientation": "auto",
+ "alert": {
+ "alertRuleTags": {},
+ "conditions": [
+ {
+ "evaluator": {
+ "params": [
+ 520850446
+ ],
+ "type": "gt"
+ },
+ "operator": {
+ "type": "and"
+ },
+ "query": {
+ "params": [
+ "A",
+ "1m",
+ "now"
+ ]
+ },
+ "reducer": {
+ "params": [],
+ "type": "max"
+ },
+ "type": "query"
+ }
+ ],
+ "executionErrorState": "alerting",
+ "for": "5m",
+ "frequency": "1m",
+ "handler": 1,
+ "message": "Memory Usage Alert",
+ "name": "Managed Memory alert",
+ "noDataState": "no_data",
+ "notifications": [
+ {
+ "uid": "N5nihcmMk"
+ }
+ ]
+ },
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 10,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "line+area"
+ }
+ },
+ "links": [],
+ "mappings": [],
+ "min": 0,
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "transparent",
+ "value": null
+ },
+ {
+ "color": "red",
+ "value": 520850446
+ }
+ ]
+ },
+ "unit": "bytes"
+ },
+ "overrides": [
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "wizards_den_eu_west"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "blue",
+ "mode": "fixed"
+ }
+ }
+ ]
+ }
+ ]
+ },
+ "gridPos": {
+ "h": 6,
+ "w": 12,
+ "x": 0,
+ "y": 24
+ },
+ "id": 9,
+ "options": {
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": true
+ },
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
+ }
+ },
+ "pluginVersion": "10.4.2",
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
+ "expr": "dotnet_total_memory_bytes",
+ "format": "time_series",
+ "interval": "",
+ "legendFormat": "{{server}}",
+ "refId": "A"
+ }
+ ],
+ "title": "Managed Memory",
+ "type": "timeseries"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 10,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "links": [],
+ "mappings": [],
+ "min": 0,
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green",
+ "value": null
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ },
+ "unit": "s"
+ },
+ "overrides": [
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "wizards_den_eu_west"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "blue",
+ "mode": "fixed"
+ }
+ }
+ ]
+ }
+ ]
+ },
+ "gridPos": {
+ "h": 6,
+ "w": 12,
+ "x": 0,
+ "y": 30
+ },
+ "id": 22,
+ "options": {
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": true
+ },
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
+ }
+ },
+ "pluginVersion": "10.4.2",
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
+ "expr": "robust_server_uptime",
+ "format": "time_series",
+ "interval": "",
+ "legendFormat": "{{server}}",
+ "refId": "A"
+ }
+ ],
+ "title": "Server Uptime",
+ "type": "timeseries"
+ }
+ ],
+ "refresh": "",
+ "schemaVersion": 39,
+ "tags": [
+ "game servers"
+ ],
+ "templating": {
+ "list": []
+ },
+ "time": {
+ "from": "now-24h",
+ "to": "now"
+ },
+ "timepicker": {
+ "refresh_intervals": [
+ "10s",
+ "30s",
+ "1m",
+ "5m",
+ "15m",
+ "30m",
+ "1h",
+ "2h",
+ "1d"
+ ]
+ },
+ "timezone": "",
+ "title": "Game Servers",
+ "uid": "K0LTdKmMk",
+ "version": 60,
+ "weekStart": ""
+}
+```
+
+## Perf Metrics
+
+```json
+{
+ "__inputs": [
+ {
+ "name": "DS_PROMETHEUS",
+ "label": "Prometheus",
+ "description": "",
+ "type": "datasource",
+ "pluginId": "prometheus",
+ "pluginName": "Prometheus"
+ },
+ {
+ "name": "DS_LOKI",
+ "label": "Loki",
+ "description": "",
+ "type": "datasource",
+ "pluginId": "loki",
+ "pluginName": "Loki"
+ }
+ ],
+ "__elements": {},
+ "__requires": [
+ {
+ "type": "panel",
+ "id": "bargauge",
+ "name": "Bar gauge",
+ "version": ""
+ },
+ {
+ "type": "grafana",
+ "id": "grafana",
+ "name": "Grafana",
+ "version": "10.4.2"
+ },
+ {
+ "type": "panel",
+ "id": "heatmap",
+ "name": "Heatmap",
+ "version": ""
+ },
+ {
+ "type": "panel",
+ "id": "logs",
+ "name": "Logs",
+ "version": ""
+ },
+ {
+ "type": "datasource",
+ "id": "loki",
+ "name": "Loki",
+ "version": "1.0.0"
+ },
+ {
+ "type": "panel",
+ "id": "piechart",
+ "name": "Pie chart",
+ "version": ""
+ },
+ {
+ "type": "datasource",
+ "id": "prometheus",
+ "name": "Prometheus",
+ "version": "1.0.0"
+ },
+ {
+ "type": "panel",
+ "id": "stat",
+ "name": "Stat",
+ "version": ""
+ },
+ {
+ "type": "panel",
+ "id": "timeseries",
+ "name": "Time series",
+ "version": ""
+ }
+ ],
+ "annotations": {
+ "list": [
+ {
+ "builtIn": 1,
+ "datasource": {
+ "type": "datasource",
+ "uid": "grafana"
+ },
+ "enable": true,
+ "hide": true,
+ "iconColor": "rgba(0, 211, 255, 1)",
+ "name": "Annotations & Alerts",
+ "target": {
+ "limit": 100,
+ "matchAny": false,
+ "tags": [],
+ "type": "dashboard"
+ },
+ "type": "dashboard"
+ }
+ ]
+ },
+ "editable": true,
+ "fiscalYearStartMonth": 0,
+ "graphTooltip": 0,
+ "id": null,
+ "links": [],
+ "liveNow": false,
+ "panels": [
+ {
+ "collapsed": true,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "fugZSFmMk"
+ },
+ "gridPos": {
+ "h": 1,
+ "w": 24,
+ "x": 0,
+ "y": 0
+ },
+ "id": 61,
+ "panels": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "thresholds"
+ },
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ }
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 3,
+ "w": 3,
+ "x": 0,
+ "y": 9
+ },
+ "id": 53,
+ "options": {
+ "colorMode": "value",
+ "graphMode": "none",
+ "justifyMode": "auto",
+ "orientation": "auto",
+ "reduceOptions": {
+ "calcs": [
+ "lastNotNull"
+ ],
+ "fields": "",
+ "values": false
+ },
+ "textMode": "name",
+ "wideLayout": true
+ },
+ "pluginVersion": "10.2.3",
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
+ "expr": "dotnet_build_info{server=\"$Server\"}",
+ "interval": "",
+ "legendFormat": "{{runtime_version}}",
+ "refId": "A"
+ }
+ ],
+ "title": "Runtime Version",
+ "type": "stat"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "thresholds"
+ },
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ }
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 3,
+ "w": 10,
+ "x": 3,
+ "y": 9
+ },
+ "id": 54,
+ "options": {
+ "colorMode": "value",
+ "graphMode": "none",
+ "justifyMode": "auto",
+ "orientation": "auto",
+ "reduceOptions": {
+ "calcs": [
+ "lastNotNull"
+ ],
+ "fields": "",
+ "values": false
+ },
+ "textMode": "name",
+ "wideLayout": true
+ },
+ "pluginVersion": "10.2.3",
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
+ "expr": "dotnet_build_info{server=\"$Server\"}",
+ "interval": "",
+ "legendFormat": "{{os_version}}",
+ "refId": "A"
+ }
+ ],
+ "title": "OS Version",
+ "type": "stat"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "thresholds"
+ },
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ }
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 3,
+ "w": 3,
+ "x": 13,
+ "y": 9
+ },
+ "id": 55,
+ "options": {
+ "colorMode": "value",
+ "graphMode": "none",
+ "justifyMode": "auto",
+ "orientation": "auto",
+ "reduceOptions": {
+ "calcs": [
+ "lastNotNull"
+ ],
+ "fields": "",
+ "values": false
+ },
+ "textMode": "name",
+ "wideLayout": true
+ },
+ "pluginVersion": "10.2.3",
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
+ "expr": "dotnet_build_info{server=\"$Server\"}",
+ "interval": "",
+ "legendFormat": "{{gc_mode}}",
+ "refId": "A"
+ }
+ ],
+ "title": "GC Mode",
+ "type": "stat"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "thresholds"
+ },
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ }
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 3,
+ "w": 3,
+ "x": 16,
+ "y": 9
+ },
+ "id": 57,
+ "options": {
+ "colorMode": "value",
+ "graphMode": "none",
+ "justifyMode": "auto",
+ "orientation": "auto",
+ "reduceOptions": {
+ "calcs": [
+ "lastNotNull"
+ ],
+ "fields": "",
+ "values": false
+ },
+ "textMode": "auto",
+ "wideLayout": true
+ },
+ "pluginVersion": "10.2.3",
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
+ "expr": "process_cpu_count{server=\"$Server\"}",
+ "interval": "",
+ "legendFormat": "",
+ "refId": "A"
+ }
+ ],
+ "title": "Processor Count",
+ "type": "stat"
+ },
+ {
+ "datasource": {
+ "type": "loki",
+ "uid": "${DS_LOKI}"
+ },
+ "description": "",
+ "gridPos": {
+ "h": 7,
+ "w": 19,
+ "x": 0,
+ "y": 12
+ },
+ "id": 34,
+ "options": {
+ "dedupStrategy": "none",
+ "enableLogDetails": true,
+ "prettifyLogMessage": false,
+ "showCommonLabels": false,
+ "showLabels": false,
+ "showTime": false,
+ "sortOrder": "Descending",
+ "wrapLogMessage": false
+ },
+ "targets": [
+ {
+ "expr": "{App=\"Robust.Server\",Server=\"$Server\"}",
+ "refId": "A",
+ "datasource": {
+ "type": "loki",
+ "uid": "${DS_LOKI}"
+ }
+ }
+ ],
+ "title": "Logs",
+ "transformations": [],
+ "type": "logs"
+ }
+ ],
+ "title": "Info",
+ "type": "row"
+ },
+ {
+ "collapsed": false,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "fugZSFmMk"
+ },
+ "gridPos": {
+ "h": 1,
+ "w": 24,
+ "x": 0,
+ "y": 1
+ },
+ "id": 24,
+ "panels": [],
+ "title": "CPU",
+ "type": "row"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 10,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "decimals": 0,
+ "links": [],
+ "mappings": [],
+ "max": 3,
+ "min": 0,
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green",
+ "value": null
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ },
+ "unit": "percentunit"
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 4,
+ "w": 6,
+ "x": 0,
+ "y": 2
+ },
+ "id": 13,
+ "options": {
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": false
+ },
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
+ }
+ },
+ "pluginVersion": "10.2.3",
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "rate(process_cpu_seconds_total{server=\"$Server\"}[$__rate_interval])",
+ "interval": "",
+ "legendFormat": "",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "title": "CPU Usage",
+ "type": "timeseries"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green",
+ "value": null
+ }
+ ]
+ },
+ "unit": "dthms"
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 4,
+ "w": 4,
+ "x": 6,
+ "y": 2
+ },
+ "id": 15,
+ "options": {
+ "colorMode": "value",
+ "graphMode": "none",
+ "justifyMode": "auto",
+ "orientation": "auto",
+ "reduceOptions": {
+ "calcs": [
+ "last"
+ ],
+ "fields": "",
+ "values": false
+ },
+ "showPercentChange": false,
+ "text": {},
+ "textMode": "auto",
+ "wideLayout": true
+ },
+ "pluginVersion": "10.4.2",
+ "targets": [
+ {
+ "expr": "robust_server_uptime{server=\"$Server\"}",
+ "interval": "",
+ "legendFormat": "",
+ "refId": "A",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ }
+ }
+ ],
+ "title": "Uptime",
+ "type": "stat"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green",
+ "value": null
+ }
+ ]
+ },
+ "unit": "dthms"
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 4,
+ "w": 4,
+ "x": 10,
+ "y": 2
+ },
+ "id": 16,
+ "options": {
+ "colorMode": "value",
+ "graphMode": "none",
+ "justifyMode": "auto",
+ "orientation": "auto",
+ "reduceOptions": {
+ "calcs": [
+ "last"
+ ],
+ "fields": "",
+ "values": false
+ },
+ "showPercentChange": false,
+ "text": {},
+ "textMode": "auto",
+ "wideLayout": true
+ },
+ "pluginVersion": "10.4.2",
+ "targets": [
+ {
+ "expr": "robust_server_curtime{server=\"$Server\"}",
+ "interval": "",
+ "legendFormat": "",
+ "refId": "A",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ }
+ }
+ ],
+ "title": "CurTime",
+ "type": "stat"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 10,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "decimals": 0,
+ "links": [],
+ "mappings": [],
+ "min": 0,
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green",
+ "value": null
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ },
+ "unit": "short"
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 4,
+ "w": 5,
+ "x": 14,
+ "y": 2
+ },
+ "id": 36,
+ "options": {
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": false
+ },
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
+ }
+ },
+ "pluginVersion": "10.4.2",
+ "targets": [
+ {
+ "expr": "robust_player_count{server=\"$Server\"}",
+ "interval": "",
+ "legendFormat": "{{job}}",
+ "refId": "A",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ }
+ }
+ ],
+ "title": "Player Count",
+ "type": "timeseries"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 15,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "auto",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green",
+ "value": null
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ },
+ "unit": "s"
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 6,
+ "w": 5,
+ "x": 0,
+ "y": 6
+ },
+ "id": 80,
+ "options": {
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": false
+ },
+ "tooltip": {
+ "mode": "single",
+ "sort": "none"
+ }
+ },
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "exemplar": true,
+ "expr": "rate(robust_game_loop_frametime_sum{server=\"$Server\"}[$__rate_interval]) / rate(robust_game_loop_frametime_count{server=\"$Server\"}[$__rate_interval])",
+ "interval": "",
+ "legendFormat": "",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "title": "Avg Tick Duration (3m)",
+ "type": "timeseries"
+ },
+ {
+ "cards": {},
+ "color": {
+ "cardColor": "#b4ff00",
+ "colorScale": "sqrt",
+ "colorScheme": "interpolateGreens",
+ "exponent": 0.5,
+ "mode": "opacity"
+ },
+ "dataFormat": "tsbuckets",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "description": "How long gameloop ticks take.",
+ "fieldConfig": {
+ "defaults": {
+ "custom": {
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "scaleDistribution": {
+ "type": "linear"
+ }
+ }
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 6,
+ "w": 7,
+ "x": 5,
+ "y": 6
+ },
+ "heatmap": {},
+ "hideZeroBuckets": false,
+ "highlightCards": true,
+ "id": 2,
+ "legend": {
+ "show": false
+ },
+ "options": {
+ "calculate": false,
+ "calculation": {},
+ "cellGap": 2,
+ "cellValues": {},
+ "color": {
+ "exponent": 0.5,
+ "fill": "#b4ff00",
+ "mode": "opacity",
+ "reverse": false,
+ "scale": "exponential",
+ "scheme": "Oranges",
+ "steps": 128
+ },
+ "exemplars": {
+ "color": "rgba(255,0,255,0.7)"
+ },
+ "filterValues": {
+ "le": 1e-9
+ },
+ "legend": {
+ "show": false
+ },
+ "rowsFrame": {
+ "layout": "auto"
+ },
+ "showValue": "never",
+ "tooltip": {
+ "mode": "single",
+ "showColorScale": false,
+ "yHistogram": false
+ },
+ "yAxis": {
+ "axisPlacement": "left",
+ "decimals": 0,
+ "reverse": false,
+ "unit": "s"
+ }
+ },
+ "pluginVersion": "10.4.2",
+ "reverseYBuckets": false,
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "rate(robust_game_loop_frametime_bucket{server=\"$Server\"}[$__rate_interval])",
+ "format": "heatmap",
+ "interval": "",
+ "legendFormat": "{{le}}",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "title": "Tick Duration",
+ "tooltip": {
+ "show": true,
+ "showHistogram": false
+ },
+ "type": "heatmap",
+ "xAxis": {
+ "show": true
+ },
+ "yAxis": {
+ "decimals": 0,
+ "format": "s",
+ "logBase": 1,
+ "show": true
+ },
+ "yBucketBound": "auto"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 10,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 2,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "links": [],
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green",
+ "value": null
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ },
+ "unit": "hertz"
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 6,
+ "w": 7,
+ "x": 12,
+ "y": 6
+ },
+ "id": 4,
+ "options": {
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": false
+ },
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
+ }
+ },
+ "pluginVersion": "10.2.3",
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "rate(robust_server_curtick{server=\"$Server\"}[$__rate_interval])",
+ "interval": "",
+ "legendFormat": "",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "title": "Tickrate",
+ "type": "timeseries"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "description": "",
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ }
+ },
+ "decimals": 0,
+ "mappings": [],
+ "unit": "s"
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 6,
+ "w": 5,
+ "x": 0,
+ "y": 12
+ },
+ "id": 43,
+ "options": {
+ "displayLabels": [],
+ "legend": {
+ "calcs": [],
+ "displayMode": "table",
+ "placement": "right",
+ "showLegend": true,
+ "values": [
+ "value"
+ ]
+ },
+ "pieType": "pie",
"reduceOptions": {
"calcs": [
- "last"
+ "lastNotNull"
],
"fields": "",
"values": false
},
+ "tooltip": {
+ "mode": "single",
+ "sort": "none"
+ }
+ },
+ "pluginVersion": "7.3.2",
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "expr": "topk(10, histogram_quantile(0.95, sum(rate(robust_entity_systems_update_usage_bucket{server=\"$Server\"}[5m])) by (le, system)))",
+ "interval": "",
+ "legendFormat": "{{system}}",
+ "refId": "A"
+ }
+ ],
+ "title": "95% System Tick Chart",
+ "type": "piechart"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green",
+ "value": null
+ },
+ {
+ "color": "red",
+ "value": 0.001
+ }
+ ]
+ },
+ "unit": "s"
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 8,
+ "w": 7,
+ "x": 5,
+ "y": 12
+ },
+ "id": 41,
+ "options": {
+ "displayMode": "gradient",
+ "maxVizHeight": 300,
+ "minVizHeight": 17,
+ "minVizWidth": 0,
+ "namePlacement": "auto",
+ "orientation": "horizontal",
+ "reduceOptions": {
+ "calcs": [
+ "mean"
+ ],
+ "fields": "",
+ "values": true
+ },
+ "showUnfilled": true,
+ "sizing": "manual",
"text": {},
- "textMode": "auto"
+ "valueMode": "color"
},
- "pluginVersion": "8.3.2",
+ "pluginVersion": "10.4.2",
"targets": [
{
- "expr": "ss14_round_length{job=\"wizards_den_eu_west\"}",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "expr": "topk(100, histogram_quantile(0.95, sum(rate(robust_entity_systems_update_usage_bucket{server=\"$Server\"}[5m])) by (le, system)))",
+ "format": "time_series",
"instant": true,
"interval": "",
- "legendFormat": "",
+ "legendFormat": "{{system}}",
"refId": "A"
}
],
- "title": "EU West Round Duration",
- "type": "stat"
+ "title": "95% System Tick Breakdown",
+ "type": "bargauge"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ }
+ },
+ "decimals": 0,
+ "mappings": [],
+ "unit": "s"
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 8,
+ "w": 7,
+ "x": 12,
+ "y": 12
+ },
+ "id": 39,
+ "options": {
+ "legend": {
+ "calcs": [],
+ "displayMode": "table",
+ "placement": "right",
+ "showLegend": true,
+ "values": [
+ "value",
+ "percent"
+ ]
+ },
+ "pieType": "pie",
+ "reduceOptions": {
+ "calcs": [
+ "lastNotNull"
+ ],
+ "fields": "",
+ "values": false
+ },
+ "tooltip": {
+ "mode": "single",
+ "sort": "none"
+ }
+ },
+ "pluginVersion": "7.1.5",
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "histogram_quantile(0.95, sum(rate(robust_server_update_usage_bucket{server=\"$Server\"}[1m])) by (le, area))",
+ "interval": "",
+ "legendFormat": "{{area}}",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "title": "95% Main Tick Timing",
+ "type": "piechart"
},
{
- "description": "EU west playercount",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
"fieldConfig": {
"defaults": {
"color": {
"mode": "thresholds"
},
- "displayName": "Players",
"mappings": [],
"thresholds": {
"mode": "absolute",
@@ -823,929 +2653,1788 @@ Contains the export for our Grafana dashboards at the time of writing. You will
{
"color": "green",
"value": null
+ },
+ {
+ "color": "red",
+ "value": 80
}
]
},
- "unit": "none"
+ "unit": "s"
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 8,
+ "w": 5,
+ "x": 0,
+ "y": 18
+ },
+ "id": 45,
+ "options": {
+ "displayMode": "gradient",
+ "maxVizHeight": 300,
+ "minVizHeight": 10,
+ "minVizWidth": 0,
+ "namePlacement": "auto",
+ "orientation": "horizontal",
+ "reduceOptions": {
+ "calcs": [
+ "lastNotNull"
+ ],
+ "fields": "",
+ "values": false
+ },
+ "showUnfilled": true,
+ "sizing": "auto",
+ "text": {},
+ "valueMode": "color"
+ },
+ "pluginVersion": "10.4.2",
+ "targets": [
+ {
+ "expr": "histogram_quantile(0.95, sum(rate(robust_entity_physics_controller_before_solve_bucket{server=\"$Server\"}[5m])) by (le, controller))",
+ "interval": "",
+ "legendFormat": "{{controller}}",
+ "refId": "A",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ }
+ }
+ ],
+ "title": "Controller Tick Breakdown",
+ "type": "bargauge"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 27,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "auto",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "mappings": [],
+ "min": 0,
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green",
+ "value": null
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ },
+ "unit": "cps"
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 6,
+ "w": 5,
+ "x": 5,
+ "y": 20
+ },
+ "id": 91,
+ "options": {
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": false
+ },
+ "tooltip": {
+ "mode": "single",
+ "sort": "none"
+ }
+ },
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "rate(dotnet_contention_total{server=\"$Server\"}[$__rate_interval])",
+ "instant": false,
+ "legendFormat": "__auto",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "title": "Lock Contentions",
+ "type": "timeseries"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "thresholds"
+ },
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green",
+ "value": null
+ }
+ ]
+ }
},
"overrides": []
},
"gridPos": {
- "h": 3,
- "w": 2,
- "x": 15,
- "y": 16
+ "h": 4,
+ "w": 3,
+ "x": 10,
+ "y": 20
},
- "id": 16,
- "links": [],
+ "id": 73,
"options": {
- "colorMode": "value",
- "graphMode": "none",
- "justifyMode": "center",
+ "colorMode": "none",
+ "graphMode": "area",
+ "justifyMode": "auto",
"orientation": "auto",
"reduceOptions": {
"calcs": [
- "last"
+ "lastNotNull"
],
"fields": "",
"values": false
},
- "text": {},
- "textMode": "auto"
+ "showPercentChange": false,
+ "textMode": "auto",
+ "wideLayout": true
},
- "pluginVersion": "8.3.2",
+ "pluginVersion": "10.4.2",
"targets": [
{
- "expr": "robust_player_count",
- "format": "time_series",
- "instant": true,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
+ "expr": "dotnet_jit_method_total{server=\"$Server\"}",
"interval": "",
- "legendFormat": "{{job}}",
+ "legendFormat": "",
"refId": "A"
}
],
- "title": "EUW",
- "transformations": [
- {
- "id": "filterFieldsByName",
- "options": {
- "include": {
- "names": [
- "Time",
- "wizards_den_eu_west"
- ]
- }
- }
- }
- ],
+ "title": "Total Methods JITed",
"type": "stat"
},
{
- "aliasColors": {
- "wizards_den_eu_west": "blue"
- },
- "bars": false,
- "dashLength": 10,
- "dashes": false,
- "fieldConfig": {
- "defaults": {
- "links": []
- },
- "overrides": []
+ "collapsed": false,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "fugZSFmMk"
},
- "fill": 1,
- "fillGradient": 0,
"gridPos": {
- "h": 6,
- "w": 10,
+ "h": 1,
+ "w": 24,
"x": 0,
- "y": 19
+ "y": 26
},
- "hiddenSeries": false,
"id": 22,
- "legend": {
- "avg": false,
- "current": false,
- "max": false,
- "min": false,
- "show": true,
- "total": false,
- "values": false
- },
- "lines": true,
- "linewidth": 1,
- "nullPointMode": "null as zero",
- "options": {
- "alertThreshold": true
- },
- "percentage": false,
- "pluginVersion": "8.3.2",
- "pointradius": 2,
- "points": false,
- "renderer": "flot",
- "seriesOverrides": [],
- "spaceLength": 10,
- "stack": false,
- "steppedLine": false,
- "targets": [
- {
- "expr": "robust_server_uptime",
- "format": "time_series",
- "interval": "",
- "legendFormat": "{{job}}",
- "refId": "A"
- }
- ],
- "thresholds": [],
- "timeRegions": [],
- "title": "Server Uptime",
- "tooltip": {
- "shared": true,
- "sort": 0,
- "value_type": "individual"
- },
- "type": "graph",
- "xaxis": {
- "mode": "time",
- "show": true,
- "values": []
- },
- "yaxes": [
- {
- "$$hashKey": "object:560",
- "format": "s",
- "logBase": 1,
- "min": "0",
- "show": true
- },
- {
- "$$hashKey": "object:561",
- "format": "short",
- "logBase": 1,
- "show": true
- }
- ],
- "yaxis": {
- "align": false
- }
+ "panels": [],
+ "title": "Network",
+ "type": "row"
},
{
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
"description": "",
"fieldConfig": {
"defaults": {
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 10,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 2,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "decimals": 0,
+ "links": [],
"mappings": [],
+ "min": 0,
"thresholds": {
"mode": "absolute",
"steps": [
{
"color": "green",
"value": null
+ },
+ {
+ "color": "red",
+ "value": 80
}
]
},
- "unit": "dthms"
+ "unit": "Bps"
},
- "overrides": []
+ "overrides": [
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Send"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "blue",
+ "mode": "fixed"
+ }
+ }
+ ]
+ }
+ ]
},
"gridPos": {
- "h": 3,
- "w": 5,
- "x": 10,
- "y": 19
+ "h": 6,
+ "w": 7,
+ "x": 0,
+ "y": 27
},
- "id": 13,
+ "id": 6,
"options": {
- "colorMode": "value",
- "graphMode": "none",
- "justifyMode": "auto",
- "orientation": "auto",
- "reduceOptions": {
- "calcs": [
- "last"
- ],
- "fields": "",
- "values": false
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": true
},
- "text": {},
- "textMode": "auto"
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
+ }
},
- "pluginVersion": "8.3.2",
+ "pluginVersion": "10.2.3",
"targets": [
{
- "expr": "ss14_round_length{job=\"wizards_den_eu_west_2\"}",
- "instant": true,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "rate(robust_net_recv_bytes{server=\"$Server\"}[$__rate_interval])",
"interval": "",
- "legendFormat": "",
+ "legendFormat": "Receive",
+ "range": true,
"refId": "A"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "rate(robust_net_sent_bytes{server=\"$Server\"}[$__rate_interval])",
+ "interval": "",
+ "legendFormat": "Send",
+ "range": true,
+ "refId": "B"
}
],
- "title": "EU West 2 Round Duration",
- "type": "stat"
+ "title": "Network Usage",
+ "type": "timeseries"
},
{
- "description": "EU west 2 playercount",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "description": "* Packets: real UDP packets.\n* Messages: Lidgren messages.\n\nLidgren can combine multiple messages into one UDP packet so these numbers are not necessarily equal. ",
"fieldConfig": {
"defaults": {
"color": {
- "mode": "thresholds"
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 10,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 2,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
},
- "displayName": "Players",
+ "decimals": 0,
+ "links": [],
"mappings": [],
+ "min": 0,
"thresholds": {
"mode": "absolute",
"steps": [
{
"color": "green",
"value": null
+ },
+ {
+ "color": "red",
+ "value": 80
}
]
},
- "unit": "none"
+ "unit": "pps"
},
- "overrides": []
+ "overrides": [
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Receive Messages"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "dark-red",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Receive Packets"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "red",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Send"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "blue",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Send Messages"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "semi-dark-blue",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Send Packets"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "blue",
+ "mode": "fixed"
+ }
+ }
+ ]
+ }
+ ]
},
"gridPos": {
- "h": 3,
- "w": 2,
- "x": 15,
- "y": 19
+ "h": 6,
+ "w": 7,
+ "x": 7,
+ "y": 27
},
- "id": 17,
- "links": [],
+ "id": 7,
"options": {
- "colorMode": "value",
- "graphMode": "none",
- "justifyMode": "center",
- "orientation": "auto",
- "reduceOptions": {
- "calcs": [
- "last"
- ],
- "fields": "",
- "values": false
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": true
},
- "text": {},
- "textMode": "auto"
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
+ }
},
- "pluginVersion": "8.3.2",
+ "pluginVersion": "10.2.3",
"targets": [
{
- "expr": "robust_player_count",
- "format": "time_series",
- "instant": true,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "rate(robust_net_recv_packets{server=\"$Server\"}[$__rate_interval])",
"interval": "",
- "legendFormat": "{{job}}",
+ "legendFormat": "Receive Packets",
+ "range": true,
"refId": "A"
- }
- ],
- "title": "EUW2",
- "transformations": [
+ },
{
- "id": "filterFieldsByName",
- "options": {
- "include": {
- "names": [
- "Time",
- "wizards_den_eu_west_2"
- ]
- }
- }
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "rate(robust_net_sent_packets{server=\"$Server\"}[$__rate_interval])",
+ "interval": "",
+ "legendFormat": "Send Packets",
+ "range": true,
+ "refId": "B"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "rate(robust_net_sent_messages{server=\"$Server\"}[$__rate_interval])",
+ "interval": "",
+ "legendFormat": "Send Messages",
+ "range": true,
+ "refId": "C"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "rate(robust_net_recv_messages{server=\"$Server\"}[$__rate_interval])",
+ "interval": "",
+ "legendFormat": "Receive Messages",
+ "range": true,
+ "refId": "D"
}
],
- "type": "stat"
+ "title": "Packets",
+ "type": "timeseries"
},
{
- "description": "",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "description": "How many messages are currently stored by Lidgren.\n\n* Stored: Reliable messages that are stored in case they need to be re-sent.\n* Unsent: Messages that have not yet been sent because of network overload.",
"fieldConfig": {
"defaults": {
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 10,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "decimals": 0,
+ "links": [],
"mappings": [],
+ "min": 0,
"thresholds": {
"mode": "absolute",
"steps": [
{
- "color": "green",
- "value": null
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
}
]
},
- "unit": "dthms"
+ "unit": "none"
},
"overrides": []
},
"gridPos": {
- "h": 3,
- "w": 5,
- "x": 10,
- "y": 22
- },
- "id": 10,
- "options": {
- "colorMode": "value",
- "graphMode": "none",
- "justifyMode": "auto",
- "orientation": "auto",
- "reduceOptions": {
- "calcs": [
- "last"
- ],
- "fields": "",
- "values": false
+ "h": 5,
+ "w": 6,
+ "x": 0,
+ "y": 33
+ },
+ "id": 28,
+ "options": {
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": true
},
- "text": {},
- "textMode": "auto"
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
+ }
},
- "pluginVersion": "8.3.2",
+ "pluginVersion": "10.2.3",
"targets": [
{
- "expr": "ss14_round_length{job=\"wizards_den_centipede\"}",
- "instant": true,
+ "expr": "robust_net_stored{server=\"$Server\"}",
"interval": "",
- "legendFormat": "",
- "refId": "A"
+ "legendFormat": "Stored",
+ "refId": "A",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ }
+ },
+ {
+ "expr": "robust_net_unsent{server=\"$Server\"}",
+ "interval": "",
+ "legendFormat": "Unsent",
+ "refId": "B",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ }
}
],
- "title": "Oceania Round Duration",
- "type": "stat"
+ "title": "Stored Messages",
+ "type": "timeseries"
},
{
- "description": "Oceania playercount",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "description": "How many reliable messages are being re-sent by Lidgren.",
"fieldConfig": {
"defaults": {
"color": {
- "mode": "thresholds"
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 10,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
},
- "displayName": "Players",
+ "decimals": 0,
+ "links": [],
"mappings": [],
+ "min": 0,
"thresholds": {
"mode": "absolute",
"steps": [
{
- "color": "green",
- "value": null
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
}
]
},
- "unit": "none"
+ "unit": "short"
},
"overrides": []
},
"gridPos": {
- "h": 3,
- "w": 2,
- "x": 15,
- "y": 22
+ "h": 5,
+ "w": 6,
+ "x": 6,
+ "y": 33
},
- "id": 18,
- "links": [],
+ "id": 30,
"options": {
- "colorMode": "value",
- "graphMode": "none",
- "justifyMode": "center",
- "orientation": "auto",
- "reduceOptions": {
- "calcs": [
- "last"
- ],
- "fields": "",
- "values": false
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": true
},
- "text": {},
- "textMode": "auto"
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
+ }
},
- "pluginVersion": "8.3.2",
+ "pluginVersion": "10.2.3",
"targets": [
{
- "expr": "robust_player_count",
- "format": "time_series",
- "instant": true,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "rate(robust_net_resent_delay{server=\"$Server\"}[$__rate_interval])",
"interval": "",
- "legendFormat": "{{job}}",
+ "legendFormat": "Delay",
+ "range": true,
"refId": "A"
- }
- ],
- "title": "OCE",
- "transformations": [
+ },
{
- "id": "filterFieldsByName",
- "options": {
- "include": {
- "names": [
- "Time",
- "wizards_den_centipede"
- ]
- }
- }
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "rate(robust_net_resent_hole{server=\"$Server\"}[$__rate_interval])",
+ "interval": "",
+ "legendFormat": "Holes",
+ "range": true,
+ "refId": "B"
}
],
- "type": "stat"
+ "title": "Resent Messages",
+ "type": "timeseries"
},
{
- "description": "",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "description": "How many messages are getting dropped by Lidgren. This usually indicates duplicates or sequencing issues.",
"fieldConfig": {
"defaults": {
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 10,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "decimals": 0,
+ "links": [],
"mappings": [],
+ "min": 0,
"thresholds": {
"mode": "absolute",
"steps": [
{
- "color": "green",
- "value": null
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
}
]
},
- "unit": "dthms"
+ "unit": "short"
},
"overrides": []
},
"gridPos": {
- "h": 3,
- "w": 5,
- "x": 10,
- "y": 25
+ "h": 5,
+ "w": 6,
+ "x": 12,
+ "y": 33
},
- "id": 14,
+ "id": 32,
"options": {
- "colorMode": "value",
- "graphMode": "none",
- "justifyMode": "auto",
- "orientation": "auto",
- "reduceOptions": {
- "calcs": [
- "last"
- ],
- "fields": "",
- "values": false
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": false
},
- "text": {},
- "textMode": "auto"
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
+ }
},
- "pluginVersion": "8.3.2",
+ "pluginVersion": "10.2.3",
"targets": [
{
- "expr": "ss14_round_length{job=\"raspberry\"}",
- "instant": true,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "rate(robust_net_dropped{server=\"$Server\"}[$__rate_interval])",
"interval": "",
"legendFormat": "",
+ "range": true,
"refId": "A"
}
],
- "title": "Raspberry Round Duration",
- "type": "stat"
+ "title": "Dropped Messages",
+ "type": "timeseries"
},
{
- "description": "Gradient/Raspberry playercount",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "description": "Shows ratio of the mapped string serializer getting hit. That means a string of text over the network could be sent as an integer ID instead of the full contents.",
"fieldConfig": {
"defaults": {
"color": {
- "mode": "thresholds"
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 20,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "auto",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "percent"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
},
- "displayName": "Players",
"mappings": [],
"thresholds": {
"mode": "absolute",
"steps": [
{
- "color": "green",
- "value": null
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
}
]
- },
- "unit": "none"
+ }
},
- "overrides": []
+ "overrides": [
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Hit"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "green",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Miss"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "red",
+ "mode": "fixed"
+ }
+ }
+ ]
+ }
+ ]
},
"gridPos": {
- "h": 3,
- "w": 2,
- "x": 15,
- "y": 25
+ "h": 7,
+ "w": 6,
+ "x": 0,
+ "y": 38
},
- "id": 19,
- "links": [],
+ "id": 84,
"options": {
- "colorMode": "value",
- "graphMode": "none",
- "justifyMode": "center",
- "orientation": "auto",
- "reduceOptions": {
- "calcs": [
- "last"
- ],
- "fields": "",
- "values": false
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": true
},
- "text": {},
- "textMode": "auto"
+ "tooltip": {
+ "mode": "single",
+ "sort": "none"
+ }
},
- "pluginVersion": "8.3.2",
"targets": [
{
- "expr": "robust_player_count",
- "format": "time_series",
- "instant": true,
- "interval": "",
- "legendFormat": "{{job}}",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "rate(robust_net_string_hit{server=\"$Server\"}[$__rate_interval])",
+ "legendFormat": "Hit",
+ "range": true,
"refId": "A"
- }
- ],
- "title": "RSP",
- "transformations": [
+ },
{
- "id": "filterFieldsByName",
- "options": {
- "include": {
- "names": [
- "raspberry",
- "Time"
- ]
- }
- }
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "exemplar": false,
+ "expr": "rate(robust_net_string_miss{server=\"$Server\"}[$__rate_interval])",
+ "hide": false,
+ "legendFormat": "Miss",
+ "range": true,
+ "refId": "B"
}
],
- "type": "stat"
- }
- ],
- "refresh": false,
- "schemaVersion": 33,
- "style": "dark",
- "tags": [
- "game servers"
- ],
- "templating": {
- "list": []
- },
- "time": {
- "from": "now-15m",
- "to": "now"
- },
- "timepicker": {
- "refresh_intervals": [
- "10s",
- "30s",
- "1m",
- "5m",
- "15m",
- "30m",
- "1h",
- "2h",
- "1d"
- ]
- },
- "timezone": "",
- "title": "Game Servers",
- "uid": "K0LTdKmMk",
- "version": 52,
- "weekStart": ""
-}
-```
-
-## Perf Metrics
-
-```json
-{
- "annotations": {
- "list": [
- {
- "builtIn": 1,
- "datasource": "-- Grafana --",
- "enable": true,
- "hide": true,
- "iconColor": "rgba(0, 211, 255, 1)",
- "name": "Annotations & Alerts",
- "target": {
- "limit": 100,
- "matchAny": false,
- "tags": [],
- "type": "dashboard"
- },
- "type": "dashboard"
- }
- ]
- },
- "editable": true,
- "fiscalYearStartMonth": 0,
- "graphTooltip": 0,
- "id": 2,
- "iteration": 1640259621461,
- "links": [],
- "liveNow": false,
- "panels": [
+ "title": "Mapped string hit rate",
+ "type": "timeseries"
+ },
{
"datasource": {
- "type": "loki",
- "uid": "DSc4tCGMk"
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 0,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "auto",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "decimals": 0,
+ "displayName": "Asd",
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ },
+ "unit": "none"
+ },
+ "overrides": []
},
- "description": "",
"gridPos": {
"h": 7,
- "w": 19,
- "x": 0,
- "y": 0
+ "w": 6,
+ "x": 6,
+ "y": 38
},
- "id": 34,
+ "id": 86,
"options": {
- "dedupStrategy": "none",
- "enableLogDetails": true,
- "prettifyLogMessage": false,
- "showCommonLabels": false,
- "showLabels": false,
- "showTime": false,
- "sortOrder": "Descending",
- "wrapLogMessage": false
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": false
+ },
+ "tooltip": {
+ "mode": "single",
+ "sort": "none"
+ }
},
"targets": [
{
- "expr": "{App=\"Robust.Server\",Server=\"$Server\"}",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "rate(robust_net_string_miss_chars{server=\"$Server\"}[$__rate_interval])",
+ "legendFormat": "__auto",
+ "range": true,
"refId": "A"
}
],
- "title": "Logs",
- "transformations": [],
- "type": "logs"
+ "title": "String serializer missed chars per second",
+ "type": "timeseries"
},
{
"collapsed": false,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "fugZSFmMk"
+ },
"gridPos": {
"h": 1,
"w": 24,
"x": 0,
- "y": 7
+ "y": 45
},
- "id": 24,
+ "id": 20,
"panels": [],
- "title": "CPU",
+ "title": "Memory",
"type": "row"
},
{
- "aliasColors": {},
- "bars": false,
- "dashLength": 10,
- "dashes": false,
- "fieldConfig": {
- "defaults": {
- "links": []
- },
- "overrides": []
- },
- "fill": 1,
- "fillGradient": 0,
- "gridPos": {
- "h": 4,
- "w": 6,
- "x": 0,
- "y": 8
- },
- "hiddenSeries": false,
- "id": 13,
- "legend": {
- "avg": false,
- "current": false,
- "max": false,
- "min": false,
- "show": false,
- "total": false,
- "values": false
- },
- "lines": true,
- "linewidth": 1,
- "nullPointMode": "null",
- "options": {
- "alertThreshold": true
- },
- "percentage": false,
- "pluginVersion": "8.3.2",
- "pointradius": 2,
- "points": false,
- "renderer": "flot",
- "seriesOverrides": [],
- "spaceLength": 10,
- "stack": false,
- "steppedLine": false,
- "targets": [
- {
- "expr": "rate(process_cpu_seconds_total{job=\"$Server\"}[10s])",
- "interval": "",
- "legendFormat": "",
- "refId": "A"
- }
- ],
- "thresholds": [],
- "timeRegions": [],
- "title": "CPU Usage",
- "tooltip": {
- "shared": true,
- "sort": 0,
- "value_type": "individual"
- },
- "type": "graph",
- "xaxis": {
- "mode": "time",
- "show": true,
- "values": []
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
},
- "yaxes": [
- {
- "$$hashKey": "object:957",
- "decimals": 0,
- "format": "percentunit",
- "logBase": 1,
- "max": "1.05",
- "min": "0",
- "show": true
- },
- {
- "$$hashKey": "object:958",
- "format": "short",
- "logBase": 1,
- "show": false
- }
- ],
- "yaxis": {
- "align": false
- }
- },
- {
"fieldConfig": {
"defaults": {
+ "color": {
+ "mode": "thresholds"
+ },
+ "decimals": 0,
"mappings": [],
"thresholds": {
"mode": "absolute",
"steps": [
{
- "color": "green",
- "value": null
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
}
]
},
- "unit": "dthms"
+ "unit": "bytes"
},
"overrides": []
},
"gridPos": {
- "h": 4,
- "w": 4,
- "x": 6,
- "y": 8
+ "h": 5,
+ "w": 2,
+ "x": 0,
+ "y": 46
},
- "id": 15,
+ "id": 69,
"options": {
- "colorMode": "value",
+ "colorMode": "none",
"graphMode": "none",
"justifyMode": "auto",
"orientation": "auto",
"reduceOptions": {
"calcs": [
- "last"
+ "lastNotNull"
],
"fields": "",
"values": false
},
- "text": {},
- "textMode": "auto"
+ "showPercentChange": false,
+ "textMode": "auto",
+ "wideLayout": true
},
- "pluginVersion": "8.3.2",
+ "pluginVersion": "10.4.2",
"targets": [
{
- "expr": "robust_server_uptime{job=\"$Server\"}",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
+ "expr": "node_memory_MemTotal_bytes{server=\"$Server\"}",
"interval": "",
"legendFormat": "",
"refId": "A"
}
],
- "title": "Uptime",
+ "title": "Total System Memory",
"type": "stat"
},
{
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "description": "Basic memory usage",
"fieldConfig": {
"defaults": {
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 40,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": true,
+ "stacking": {
+ "group": "A",
+ "mode": "normal"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "links": [],
"mappings": [],
+ "min": 0,
"thresholds": {
"mode": "absolute",
"steps": [
{
- "color": "green",
- "value": null
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
}
]
},
- "unit": "dthms"
+ "unit": "bytes"
},
- "overrides": []
+ "overrides": [
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Apps"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#629E51",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Buffers"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#614D93",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Cache"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#6D1F62",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Cached"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#511749",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Committed"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#508642",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Free"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#0A437C",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Hardware Corrupted - Amount of RAM that the kernel identified as corrupted / not working"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#CFFAFF",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Inactive"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#584477",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "PageTables"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#0A50A1",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Page_Tables"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#0A50A1",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "RAM_Free"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#E0F9D7",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "SWAP Used"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#BF1B00",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Slab"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#806EB7",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Slab_Cache"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#E0752D",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Swap"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#BF1B00",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Swap Used"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#BF1B00",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Swap_Cache"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#C15C17",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Swap_Free"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#2F575E",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Unused"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#EAB839",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "RAM Total"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#E0F9D7",
+ "mode": "fixed"
+ }
+ },
+ {
+ "id": "custom.fillOpacity",
+ "value": 0
+ },
+ {
+ "id": "custom.stacking",
+ "value": {
+ "group": false,
+ "mode": "normal"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "RAM Cache + Buffer"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#052B51",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "RAM Free"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#7EB26D",
+ "mode": "fixed"
+ }
+ }
+ ]
+ },
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "Avaliable"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "#DEDAF7",
+ "mode": "fixed"
+ }
+ },
+ {
+ "id": "custom.fillOpacity",
+ "value": 0
+ },
+ {
+ "id": "custom.stacking",
+ "value": {
+ "group": false,
+ "mode": "normal"
+ }
+ }
+ ]
+ }
+ ]
},
"gridPos": {
- "h": 4,
- "w": 4,
- "x": 10,
- "y": 8
+ "h": 5,
+ "w": 10,
+ "x": 2,
+ "y": 46
},
- "id": 16,
+ "id": 78,
"options": {
- "colorMode": "value",
- "graphMode": "none",
- "justifyMode": "auto",
- "orientation": "auto",
- "reduceOptions": {
- "calcs": [
- "last"
- ],
- "fields": "",
- "values": false
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": true
},
- "text": {},
- "textMode": "auto"
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
+ }
},
- "pluginVersion": "8.3.2",
+ "pluginVersion": "8.3.3",
"targets": [
{
- "expr": "robust_server_curtime{job=\"$Server\"}",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
+ "expr": "node_memory_MemTotal_bytes{server=\"$Server\"}",
+ "format": "time_series",
+ "hide": false,
"interval": "",
- "legendFormat": "",
- "refId": "A"
- }
- ],
- "title": "CurTime",
- "type": "stat"
- },
- {
- "aliasColors": {},
- "bars": false,
- "dashLength": 10,
- "dashes": false,
- "fieldConfig": {
- "defaults": {
- "links": []
+ "intervalFactor": 2,
+ "legendFormat": "RAM Total",
+ "refId": "A",
+ "step": 240
},
- "overrides": []
- },
- "fill": 1,
- "fillGradient": 0,
- "gridPos": {
- "h": 4,
- "w": 5,
- "x": 14,
- "y": 8
- },
- "hiddenSeries": false,
- "id": 36,
- "legend": {
- "avg": false,
- "current": false,
- "max": false,
- "min": false,
- "show": false,
- "total": false,
- "values": false
- },
- "lines": true,
- "linewidth": 1,
- "nullPointMode": "null",
- "options": {
- "alertThreshold": true
- },
- "percentage": false,
- "pluginVersion": "8.3.2",
- "pointradius": 2,
- "points": false,
- "renderer": "flot",
- "seriesOverrides": [],
- "spaceLength": 10,
- "stack": false,
- "steppedLine": false,
- "targets": [
{
- "expr": "robust_player_count{job=\"$Server\"}",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
+ "expr": "node_memory_MemTotal_bytes{server=\"$Server\"} - node_memory_MemFree_bytes{server=\"$Server\"} - (node_memory_Cached_bytes{server=\"$Server\"} + node_memory_Buffers_bytes{server=\"$Server\"})",
+ "format": "time_series",
+ "hide": false,
"interval": "",
- "legendFormat": "{{job}}",
- "refId": "A"
- }
- ],
- "thresholds": [],
- "timeRegions": [],
- "title": "Player Count",
- "tooltip": {
- "shared": true,
- "sort": 0,
- "value_type": "individual"
- },
- "type": "graph",
- "xaxis": {
- "mode": "time",
- "show": true,
- "values": []
- },
- "yaxes": [
+ "intervalFactor": 2,
+ "legendFormat": "RAM Used",
+ "refId": "B",
+ "step": 240
+ },
{
- "$$hashKey": "object:145",
- "decimals": 0,
- "format": "short",
- "logBase": 1,
- "min": "0",
- "show": true
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "expr": "node_memory_Cached_bytes{server=\"$Server\"} + node_memory_Buffers_bytes{server=\"$Server\"}",
+ "format": "time_series",
+ "intervalFactor": 2,
+ "legendFormat": "RAM Cache + Buffer",
+ "refId": "C",
+ "step": 240
},
{
- "$$hashKey": "object:146",
- "format": "short",
- "logBase": 1,
- "show": false
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "expr": "node_memory_MemFree_bytes{server=\"$Server\"}",
+ "format": "time_series",
+ "intervalFactor": 2,
+ "legendFormat": "RAM Free",
+ "refId": "D",
+ "step": 240
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "expr": "(node_memory_SwapTotal_bytes{server=\"$Server\"} - node_memory_SwapFree_bytes{server=\"$Server\"})",
+ "format": "time_series",
+ "intervalFactor": 2,
+ "legendFormat": "SWAP Used",
+ "refId": "E",
+ "step": 240
}
],
- "yaxis": {
- "align": false
- }
+ "title": "System Memory",
+ "type": "timeseries"
},
{
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
"fieldConfig": {
"defaults": {
"color": {
- "mode": "thresholds"
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 10,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
},
+ "links": [],
"mappings": [],
+ "min": 0,
"thresholds": {
"mode": "absolute",
"steps": [
{
- "color": "green",
- "value": null
+ "color": "green"
},
{
"color": "red",
@@ -1755,177 +4444,67 @@ Contains the export for our Grafana dashboards at the time of writing. You will
},
"unit": "s"
},
- "overrides": []
+ "overrides": [
+ {
+ "matcher": {
+ "id": "byName",
+ "options": "wizards_den_eu_west"
+ },
+ "properties": [
+ {
+ "id": "color",
+ "value": {
+ "fixedColor": "blue",
+ "mode": "fixed"
+ }
+ }
+ ]
+ }
+ ]
},
"gridPos": {
- "h": 8,
- "w": 5,
- "x": 0,
- "y": 12
+ "h": 6,
+ "w": 10,
+ "x": 12,
+ "y": 46
},
- "id": 45,
+ "id": 82,
"options": {
- "displayMode": "gradient",
- "orientation": "horizontal",
- "reduceOptions": {
- "calcs": [
- "lastNotNull"
- ],
- "fields": "",
- "values": false
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": true
},
- "showUnfilled": true,
- "text": {}
- },
- "pluginVersion": "8.3.2",
- "targets": [
- {
- "expr": "histogram_quantile(0.95, sum(rate(robust_entity_physics_controller_before_solve_bucket{job=\"$Server\"}[5m])) by (le, controller))",
- "interval": "",
- "legendFormat": "{{controller}}",
- "refId": "A"
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
}
- ],
- "title": "Controller Tick Breakdown",
- "type": "bargauge"
- },
- {
- "cards": {},
- "color": {
- "cardColor": "#b4ff00",
- "colorScale": "sqrt",
- "colorScheme": "interpolateGreens",
- "exponent": 0.5,
- "mode": "opacity"
- },
- "dataFormat": "tsbuckets",
- "description": "How long gameloop ticks take.",
- "gridPos": {
- "h": 6,
- "w": 7,
- "x": 5,
- "y": 12
- },
- "heatmap": {},
- "hideZeroBuckets": false,
- "highlightCards": true,
- "id": 2,
- "legend": {
- "show": false
},
- "reverseYBuckets": false,
+ "pluginVersion": "10.4.2",
"targets": [
{
- "expr": "rate(robust_game_loop_frametime_bucket{job=\"$Server\"}[10s])",
- "format": "heatmap",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
+ "expr": "robust_server_uptime{server=\"$Server\"}",
+ "format": "time_series",
"interval": "",
- "legendFormat": "{{le}}",
+ "legendFormat": "{{server}}",
"refId": "A"
}
],
- "title": "Tick Duration",
- "tooltip": {
- "show": true,
- "showHistogram": false
- },
- "type": "heatmap",
- "xAxis": {
- "show": true
- },
- "yAxis": {
- "decimals": 0,
- "format": "s",
- "logBase": 1,
- "show": true
- },
- "yBucketBound": "auto"
+ "title": "Server Uptime",
+ "type": "timeseries"
},
{
- "aliasColors": {},
- "bars": false,
- "dashLength": 10,
- "dashes": false,
- "fieldConfig": {
- "defaults": {
- "links": []
- },
- "overrides": []
- },
- "fill": 1,
- "fillGradient": 0,
- "gridPos": {
- "h": 6,
- "w": 7,
- "x": 12,
- "y": 12
- },
- "hiddenSeries": false,
- "id": 4,
- "legend": {
- "avg": false,
- "current": false,
- "max": false,
- "min": false,
- "show": false,
- "total": false,
- "values": false
- },
- "lines": true,
- "linewidth": 2,
- "nullPointMode": "null",
- "options": {
- "alertThreshold": true
- },
- "percentage": false,
- "pluginVersion": "8.3.2",
- "pointradius": 2,
- "points": false,
- "renderer": "flot",
- "seriesOverrides": [],
- "spaceLength": 10,
- "stack": false,
- "steppedLine": false,
- "targets": [
- {
- "expr": "rate(robust_server_curtick{job=\"$Server\"}[10s])",
- "interval": "",
- "legendFormat": "",
- "refId": "A"
- }
- ],
- "thresholds": [],
- "timeRegions": [],
- "title": "Tickrate",
- "tooltip": {
- "shared": true,
- "sort": 0,
- "value_type": "individual"
- },
- "type": "graph",
- "xaxis": {
- "mode": "time",
- "show": true,
- "values": []
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
},
- "yaxes": [
- {
- "$$hashKey": "object:350",
- "format": "hertz",
- "logBase": 1,
- "show": true
- },
- {
- "$$hashKey": "object:351",
- "format": "short",
- "logBase": 1,
- "show": true
- }
- ],
- "yaxis": {
- "align": false
- }
- },
- {
+ "description": "How often the GC is running, by generation.",
"fieldConfig": {
"defaults": {
"mappings": [],
@@ -1933,676 +4512,561 @@ Contains the export for our Grafana dashboards at the time of writing. You will
"mode": "absolute",
"steps": [
{
- "color": "green",
- "value": null
+ "color": "green"
},
{
"color": "red",
- "value": 0.001
+ "value": 1.5
}
]
},
- "unit": "s"
+ "unit": "none"
},
"overrides": []
},
"gridPos": {
- "h": 8,
- "w": 7,
- "x": 5,
- "y": 18
+ "h": 4,
+ "w": 12,
+ "x": 0,
+ "y": 51
},
- "id": 41,
+ "id": 18,
"options": {
- "displayMode": "gradient",
- "orientation": "horizontal",
+ "colorMode": "value",
+ "graphMode": "area",
+ "justifyMode": "auto",
+ "orientation": "auto",
"reduceOptions": {
"calcs": [
- "mean"
+ "last"
],
"fields": "",
- "values": true
- },
- "showUnfilled": true,
- "text": {}
- },
- "pluginVersion": "8.3.2",
- "targets": [
- {
- "expr": "topk(10, histogram_quantile(0.95, sum(rate(robust_entity_systems_update_usage_bucket{job=\"$Server\"}[5m])) by (le, system)))",
- "format": "time_series",
- "instant": true,
- "interval": "",
- "legendFormat": "{{system}}",
- "refId": "A"
- }
- ],
- "title": "95% System Tick Breakdown",
- "transformations": [],
- "type": "bargauge"
- },
- {
- "aliasColors": {},
- "breakPoint": "50%",
- "combine": {
- "label": "Others",
- "threshold": 0
- },
- "decimals": 0,
- "fontSize": "80%",
- "format": "s",
- "gridPos": {
- "h": 8,
- "w": 7,
- "x": 12,
- "y": 18
- },
- "id": 39,
- "legend": {
- "percentage": true,
- "show": true,
- "sort": "current",
- "sortDesc": true,
- "values": true
- },
- "legendType": "Right side",
- "links": [],
- "nullPointMode": "connected",
- "pieType": "pie",
- "pluginVersion": "7.1.5",
- "strokeWidth": "0.25",
- "targets": [
- {
- "expr": "histogram_quantile(0.95, sum(rate(robust_server_update_usage_bucket[1m])) by (le, area))",
- "interval": "",
- "legendFormat": "{{area}}",
- "refId": "A"
- }
- ],
- "title": "95% Main Tick Timing",
- "type": "grafana-piechart-panel",
- "valueName": "current"
- },
- {
- "aliasColors": {},
- "breakPoint": "50%",
- "combine": {
- "label": "Others",
- "threshold": 0
- },
- "description": "",
- "fontSize": "50%",
- "format": "s",
- "gridPos": {
- "h": 6,
- "w": 5,
- "x": 0,
- "y": 20
+ "values": false
+ },
+ "showPercentChange": false,
+ "text": {},
+ "textMode": "auto",
+ "wideLayout": true
},
- "id": 43,
- "legend": {
- "header": "",
- "show": false,
- "sideWidth": 10,
- "values": true
- },
- "legendType": "On graph",
- "links": [],
- "nullPointMode": "connected",
- "pieType": "pie",
- "pluginVersion": "7.3.2",
- "strokeWidth": "1",
+ "pluginVersion": "10.4.2",
"targets": [
{
- "expr": "topk(10, histogram_quantile(0.95, sum(rate(robust_entity_systems_update_usage_bucket{job=\"$Server\"}[5m])) by (le, system)))",
+ "expr": "rate(dotnet_collection_count_total{server=\"$Server\"}[1m])",
"interval": "",
- "legendFormat": "{{system}}",
- "refId": "A"
+ "legendFormat": "{{generation}}",
+ "refId": "A",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ }
}
],
- "title": "95% System Tick Chart",
- "type": "grafana-piechart-panel",
- "valueName": "current"
- },
- {
- "collapsed": false,
- "gridPos": {
- "h": 1,
- "w": 24,
- "x": 0,
- "y": 26
- },
- "id": 22,
- "panels": [],
- "title": "Network",
- "type": "row"
+ "title": "GC Per Minute",
+ "type": "stat"
},
{
- "aliasColors": {
- "Send": "blue"
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
},
- "bars": false,
- "dashLength": 10,
- "dashes": false,
- "description": "",
+ "description": "Managed and working set memory",
"fieldConfig": {
"defaults": {
- "links": []
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 10,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 2,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "normal"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "links": [],
+ "mappings": [],
+ "min": 0,
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ },
+ "unit": "bytes"
},
"overrides": []
},
- "fill": 1,
- "fillGradient": 0,
"gridPos": {
- "h": 6,
- "w": 7,
+ "h": 5,
+ "w": 6,
"x": 0,
- "y": 27
- },
- "hiddenSeries": false,
- "id": 6,
- "legend": {
- "avg": false,
- "current": false,
- "max": false,
- "min": false,
- "show": true,
- "total": false,
- "values": false
+ "y": 55
},
- "lines": true,
- "linewidth": 2,
- "nullPointMode": "null",
+ "id": 9,
"options": {
- "alertThreshold": true
- },
- "percentage": false,
- "pluginVersion": "8.3.2",
- "pointradius": 2,
- "points": false,
- "renderer": "flot",
- "seriesOverrides": [],
- "spaceLength": 10,
- "stack": false,
- "steppedLine": false,
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": false
+ },
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
+ }
+ },
+ "pluginVersion": "10.4.2",
"targets": [
{
- "expr": "rate(robust_net_recv_bytes{job=\"$Server\"}[10s])",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
+ "expr": "dotnet_total_memory_bytes{server=\"$Server\"}",
"interval": "",
- "legendFormat": "Receive",
+ "legendFormat": "Managed memory",
"refId": "A"
},
{
- "expr": "rate(robust_net_sent_bytes{job=\"$Server\"}[10s])",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
+ "expr": "process_working_set_bytes{server=\"$Server\"}-dotnet_total_memory_bytes{server=\"$Server\"}",
+ "hide": false,
"interval": "",
- "legendFormat": "Send",
+ "legendFormat": "Working Set (Extra)",
"refId": "B"
}
],
- "thresholds": [],
- "timeRegions": [],
- "title": "Network Usage",
- "tooltip": {
- "shared": true,
- "sort": 0,
- "value_type": "individual"
- },
- "type": "graph",
- "xaxis": {
- "mode": "time",
- "show": true,
- "values": []
- },
- "yaxes": [
- {
- "$$hashKey": "object:268",
- "decimals": 0,
- "format": "Bps",
- "logBase": 1,
- "min": "0",
- "show": true
- },
- {
- "$$hashKey": "object:269",
- "format": "short",
- "logBase": 1,
- "show": false
- }
- ],
- "yaxis": {
- "align": false
- }
+ "title": "Memory",
+ "type": "timeseries"
},
{
- "aliasColors": {
- "Receive Messages": "dark-red",
- "Receive Packets": "red",
- "Send": "blue",
- "Send Messages": "semi-dark-blue",
- "Send Packets": "blue"
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
},
- "bars": false,
- "dashLength": 10,
- "dashes": false,
- "description": "* Packets: real UDP packets.\n* Messages: Lidgren messages.\n\nLidgren can combine multiple messages into one UDP packet so these numbers are not necessarily equal. ",
"fieldConfig": {
"defaults": {
- "links": []
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 10,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 2,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "links": [],
+ "mappings": [],
+ "min": 0,
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ },
+ "unit": "short"
},
"overrides": []
},
- "fill": 1,
- "fillGradient": 0,
"gridPos": {
- "h": 6,
- "w": 7,
- "x": 7,
- "y": 27
- },
- "hiddenSeries": false,
- "id": 7,
- "legend": {
- "avg": false,
- "current": false,
- "max": false,
- "min": false,
- "show": true,
- "total": false,
- "values": false
+ "h": 5,
+ "w": 6,
+ "x": 6,
+ "y": 55
},
- "lines": true,
- "linewidth": 2,
- "nullPointMode": "null",
+ "id": 11,
"options": {
- "alertThreshold": true
- },
- "percentage": false,
- "pluginVersion": "8.3.2",
- "pointradius": 2,
- "points": false,
- "renderer": "flot",
- "seriesOverrides": [],
- "spaceLength": 10,
- "stack": false,
- "steppedLine": false,
- "targets": [
- {
- "expr": "rate(robust_net_recv_packets{job=\"$Server\"}[10s])",
- "interval": "",
- "legendFormat": "Receive Packets",
- "refId": "A"
- },
- {
- "expr": "rate(robust_net_sent_packets{job=\"$Server\"}[10s])",
- "interval": "",
- "legendFormat": "Send Packets",
- "refId": "B"
- },
- {
- "expr": "rate(robust_net_sent_messages{job=\"$Server\"}[10s])",
- "interval": "",
- "legendFormat": "Send Messages",
- "refId": "C"
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": false
},
- {
- "expr": "rate(robust_net_recv_messages{job=\"$Server\"}[10s])",
- "interval": "",
- "legendFormat": "Receive Messages",
- "refId": "D"
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
}
- ],
- "thresholds": [],
- "timeRegions": [],
- "title": "Packets",
- "tooltip": {
- "shared": true,
- "sort": 0,
- "value_type": "individual"
- },
- "type": "graph",
- "xaxis": {
- "mode": "time",
- "show": true,
- "values": []
},
- "yaxes": [
- {
- "$$hashKey": "object:268",
- "decimals": 0,
- "format": "pps",
- "logBase": 1,
- "min": "0",
- "show": true
- },
+ "pluginVersion": "10.4.2",
+ "targets": [
{
- "$$hashKey": "object:269",
- "format": "short",
- "logBase": 1,
- "show": false
+ "expr": "robust_entities_count{server=\"$Server\"}",
+ "interval": "",
+ "legendFormat": "",
+ "refId": "A",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ }
}
],
- "yaxis": {
- "align": false
- }
+ "title": "Game Entity Count",
+ "type": "timeseries"
},
{
- "aliasColors": {},
- "bars": false,
- "dashLength": 10,
- "dashes": false,
- "description": "How many messages are currently stored by Lidgren.\n\n* Stored: Reliable messages that are stored in case they need to be re-sent.\n* Unsent: Messages that have not yet been sent because of network overload.",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
"fieldConfig": {
"defaults": {
- "links": []
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 10,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "never",
+ "spanNulls": true,
+ "stacking": {
+ "group": "A",
+ "mode": "normal"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ },
+ "unit": "binBps"
},
"overrides": []
},
- "fill": 1,
- "fillGradient": 0,
"gridPos": {
"h": 5,
"w": 6,
"x": 0,
- "y": 33
- },
- "hiddenSeries": false,
- "id": 28,
- "legend": {
- "avg": false,
- "current": false,
- "max": false,
- "min": false,
- "show": true,
- "total": false,
- "values": false
+ "y": 60
},
- "lines": true,
- "linewidth": 1,
- "nullPointMode": "null",
+ "id": 47,
"options": {
- "alertThreshold": true
- },
- "percentage": false,
- "pluginVersion": "8.3.2",
- "pointradius": 2,
- "points": false,
- "renderer": "flot",
- "seriesOverrides": [],
- "spaceLength": 10,
- "stack": false,
- "steppedLine": false,
- "targets": [
- {
- "expr": "robust_net_stored{job=\"$Server\"}",
- "interval": "",
- "legendFormat": "Stored",
- "refId": "A"
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": true
},
- {
- "expr": "robust_net_unsent{job=\"$Server\"}",
- "interval": "",
- "legendFormat": "Unsent",
- "refId": "B"
+ "tooltip": {
+ "mode": "multi",
+ "sort": "none"
}
- ],
- "thresholds": [],
- "timeRegions": [],
- "title": "Stored Messages",
- "tooltip": {
- "shared": true,
- "sort": 0,
- "value_type": "individual"
- },
- "type": "graph",
- "xaxis": {
- "mode": "time",
- "show": true,
- "values": []
},
- "yaxes": [
+ "pluginVersion": "8.3.3",
+ "targets": [
{
- "$$hashKey": "object:134",
- "decimals": 0,
- "format": "none",
- "logBase": 1,
- "min": "0",
- "show": true
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "exemplar": true,
+ "expr": "rate(dotnet_gc_allocated_bytes_total{server=\"$Server\",gc_heap=\"loh\"}[$__rate_interval])",
+ "hide": false,
+ "interval": "",
+ "intervalFactor": 1,
+ "legendFormat": "Large Object Heap",
+ "range": true,
+ "refId": "B"
},
{
- "$$hashKey": "object:135",
- "format": "short",
- "logBase": 1,
- "show": false
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "exemplar": true,
+ "expr": "rate(dotnet_gc_allocated_bytes_total{server=\"$Server\",gc_heap=\"soh\"}[$__rate_interval])",
+ "interval": "",
+ "intervalFactor": 1,
+ "legendFormat": "Small Object Heap",
+ "range": true,
+ "refId": "A"
}
],
- "yaxis": {
- "align": false
- }
+ "title": "Alloc Rate",
+ "type": "timeseries"
},
{
- "aliasColors": {},
- "bars": false,
- "dashLength": 10,
- "dashes": false,
- "description": "How many reliable messages are being re-sent by Lidgren.",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
"fieldConfig": {
"defaults": {
- "links": []
+ "color": {
+ "mode": "thresholds"
+ },
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ },
+ "unit": "percentunit"
},
"overrides": []
},
- "fill": 1,
- "fillGradient": 0,
"gridPos": {
"h": 5,
- "w": 6,
+ "w": 3,
"x": 6,
- "y": 33
+ "y": 60
},
- "hiddenSeries": false,
- "id": 30,
- "legend": {
- "avg": false,
- "current": false,
- "max": false,
- "min": false,
- "show": true,
- "total": false,
- "values": false
- },
- "lines": true,
- "linewidth": 1,
- "nullPointMode": "null",
+ "id": 49,
"options": {
- "alertThreshold": true
- },
- "percentage": false,
- "pluginVersion": "8.3.2",
- "pointradius": 2,
- "points": false,
- "renderer": "flot",
- "seriesOverrides": [],
- "spaceLength": 10,
- "stack": false,
- "steppedLine": false,
- "targets": [
- {
- "expr": "rate(robust_net_resent_delay{job=\"$Server\"}[10s])",
- "interval": "",
- "legendFormat": "Delay",
- "refId": "A"
+ "colorMode": "value",
+ "graphMode": "area",
+ "justifyMode": "auto",
+ "orientation": "auto",
+ "reduceOptions": {
+ "calcs": [
+ "lastNotNull"
+ ],
+ "fields": "",
+ "values": false
},
- {
- "expr": "rate(robust_net_resent_hole{job=\"$Server\"}[10s])",
- "interval": "",
- "legendFormat": "Holes",
- "refId": "B"
- }
- ],
- "thresholds": [],
- "timeRegions": [],
- "title": "Resent Messages",
- "tooltip": {
- "shared": true,
- "sort": 0,
- "value_type": "individual"
- },
- "type": "graph",
- "xaxis": {
- "mode": "time",
- "show": true,
- "values": []
+ "showPercentChange": false,
+ "textMode": "auto",
+ "wideLayout": true
},
- "yaxes": [
- {
- "$$hashKey": "object:614",
- "decimals": 0,
- "format": "short",
- "logBase": 1,
- "min": "0",
- "show": true
- },
+ "pluginVersion": "10.4.2",
+ "targets": [
{
- "$$hashKey": "object:615",
- "format": "short",
- "logBase": 1,
- "show": true
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
+ "expr": "dotnet_gc_pause_ratio{server=\"$Server\"}",
+ "interval": "",
+ "legendFormat": "",
+ "refId": "A"
}
],
- "yaxis": {
- "align": false
- }
+ "title": "GC Pause Ratio",
+ "type": "stat"
},
{
- "aliasColors": {},
- "bars": false,
- "dashLength": 10,
- "dashes": false,
- "description": "How many messages are getting dropped by Lidgren. This usually indicates duplicates or sequencing issues.",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
"fieldConfig": {
"defaults": {
- "links": []
+ "color": {
+ "mode": "thresholds"
+ },
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ },
+ "unit": "s"
},
"overrides": []
},
- "fill": 1,
- "fillGradient": 0,
"gridPos": {
"h": 5,
- "w": 6,
- "x": 12,
- "y": 33
+ "w": 3,
+ "x": 9,
+ "y": 60
},
- "hiddenSeries": false,
- "id": 32,
- "legend": {
- "avg": false,
- "current": false,
- "max": false,
- "min": false,
- "show": false,
- "total": false,
- "values": false
- },
- "lines": true,
- "linewidth": 1,
- "nullPointMode": "null",
+ "id": 51,
"options": {
- "alertThreshold": true
- },
- "percentage": false,
- "pluginVersion": "8.3.2",
- "pointradius": 2,
- "points": false,
- "renderer": "flot",
- "seriesOverrides": [],
- "spaceLength": 10,
- "stack": false,
- "steppedLine": false,
+ "colorMode": "value",
+ "graphMode": "area",
+ "justifyMode": "auto",
+ "orientation": "auto",
+ "reduceOptions": {
+ "calcs": [
+ "lastNotNull"
+ ],
+ "fields": "",
+ "values": false
+ },
+ "showPercentChange": false,
+ "textMode": "auto",
+ "wideLayout": true
+ },
+ "pluginVersion": "10.4.2",
"targets": [
{
- "expr": "rate(robust_net_dropped{job=\"$Server\"}[10s])",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
+ "expr": "rate(dotnet_gc_pause_seconds_sum{server=\"$Server\"}[1m])",
"interval": "",
"legendFormat": "",
"refId": "A"
}
],
- "thresholds": [],
- "timeRegions": [],
- "title": "Dropped Messages",
- "tooltip": {
- "shared": true,
- "sort": 0,
- "value_type": "individual"
- },
- "type": "graph",
- "xaxis": {
- "mode": "time",
- "show": true,
- "values": []
- },
- "yaxes": [
- {
- "$$hashKey": "object:701",
- "decimals": 0,
- "format": "short",
- "logBase": 1,
- "min": "0",
- "show": true
- },
- {
- "$$hashKey": "object:702",
- "format": "short",
- "logBase": 1,
- "show": false
- }
- ],
- "yaxis": {
- "align": false
- }
+ "title": "GC Pause duration",
+ "type": "stat"
},
{
"collapsed": false,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "fugZSFmMk"
+ },
"gridPos": {
"h": 1,
"w": 24,
"x": 0,
- "y": 38
+ "y": 65
},
- "id": 20,
+ "id": 63,
"panels": [],
- "title": "Memory",
+ "title": "Thread Pool",
"type": "row"
},
{
- "description": "How often the GC is running, by generation.",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
"fieldConfig": {
"defaults": {
+ "color": {
+ "mode": "thresholds"
+ },
"mappings": [],
"thresholds": {
"mode": "absolute",
"steps": [
{
- "color": "green",
- "value": null
+ "color": "green"
},
{
"color": "red",
- "value": 1.5
+ "value": 80
}
]
- },
- "unit": "none"
+ }
},
"overrides": []
},
"gridPos": {
"h": 5,
- "w": 14,
+ "w": 3,
"x": 0,
- "y": 39
+ "y": 66
},
- "id": 18,
+ "id": 59,
"options": {
"colorMode": "value",
"graphMode": "area",
@@ -2610,212 +5074,363 @@ Contains the export for our Grafana dashboards at the time of writing. You will
"orientation": "auto",
"reduceOptions": {
"calcs": [
- "last"
+ "lastNotNull"
],
"fields": "",
"values": false
},
- "text": {},
- "textMode": "auto"
+ "showPercentChange": false,
+ "textMode": "auto",
+ "wideLayout": true
},
- "pluginVersion": "8.3.2",
+ "pluginVersion": "10.4.2",
"targets": [
{
- "expr": "rate(dotnet_collection_count_total{job=\"$Server\"}[1m])",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "exemplar": true,
+ "expr": "dotnet_threadpool_num_threads{server=\"$Server\"}",
"interval": "",
- "legendFormat": "{{generation}}",
+ "legendFormat": "",
"refId": "A"
}
],
- "title": "GC Per Minute",
+ "title": "Thread Pool Thread Count",
"type": "stat"
},
{
- "aliasColors": {},
- "bars": false,
- "dashLength": 10,
- "dashes": false,
- "description": "Managed and working set memory",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
"fieldConfig": {
"defaults": {
- "links": []
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 15,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "auto",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ }
},
"overrides": []
},
- "fill": 1,
- "fillGradient": 0,
"gridPos": {
"h": 5,
- "w": 6,
- "x": 0,
- "y": 44
+ "w": 5,
+ "x": 3,
+ "y": 66
},
- "hiddenSeries": false,
- "id": 9,
- "legend": {
- "avg": false,
- "current": false,
- "max": false,
- "min": false,
- "show": false,
- "total": false,
- "values": false
- },
- "lines": true,
- "linewidth": 2,
- "nullPointMode": "null",
+ "id": 65,
"options": {
- "alertThreshold": true
- },
- "percentage": false,
- "pluginVersion": "8.3.2",
- "pointradius": 2,
- "points": false,
- "renderer": "flot",
- "seriesOverrides": [],
- "spaceLength": 10,
- "stack": true,
- "steppedLine": false,
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": false
+ },
+ "tooltip": {
+ "mode": "single",
+ "sort": "none"
+ }
+ },
"targets": [
{
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
"exemplar": true,
- "expr": "dotnet_total_memory_bytes{job=\"$Server\"}",
+ "expr": "rate(dotnet_threadpool_throughput_total{server=\"$Server\"}[$__rate_interval])",
"interval": "",
- "legendFormat": "Managed memory",
+ "legendFormat": "",
+ "range": true,
"refId": "A"
- },
- {
- "exemplar": true,
- "expr": "process_working_set_bytes{job=\"$Server\"}-dotnet_total_memory_bytes{job=\"$Server\"}",
- "hide": false,
- "interval": "",
- "legendFormat": "Working Set (Extra)",
- "refId": "B"
- }
- ],
- "thresholds": [],
- "timeRegions": [],
- "title": "Memory",
- "tooltip": {
- "shared": true,
- "sort": 0,
- "value_type": "individual"
- },
- "type": "graph",
- "xaxis": {
- "mode": "time",
- "show": true,
- "values": []
- },
- "yaxes": [
- {
- "$$hashKey": "object:449",
- "format": "bytes",
- "logBase": 1,
- "min": "0",
- "show": true
- },
- {
- "$$hashKey": "object:450",
- "format": "short",
- "logBase": 1,
- "show": false
}
],
- "yaxis": {
- "align": false
- }
+ "title": "Thread Pool Item Rate",
+ "type": "timeseries"
},
{
- "aliasColors": {},
- "bars": false,
- "dashLength": 10,
- "dashes": false,
+ "cards": {},
+ "color": {
+ "cardColor": "#73BF69",
+ "colorScale": "linear",
+ "colorScheme": "interpolateGreens",
+ "exponent": 0.5,
+ "mode": "opacity"
+ },
+ "dataFormat": "tsbuckets",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
"fieldConfig": {
"defaults": {
- "links": []
+ "custom": {
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "scaleDistribution": {
+ "type": "linear"
+ }
+ }
},
"overrides": []
},
- "fill": 1,
- "fillGradient": 0,
"gridPos": {
"h": 5,
- "w": 6,
- "x": 6,
- "y": 44
+ "w": 5,
+ "x": 8,
+ "y": 66
},
- "hiddenSeries": false,
- "id": 11,
+ "heatmap": {},
+ "hideZeroBuckets": false,
+ "highlightCards": true,
+ "id": 67,
"legend": {
- "avg": false,
- "current": false,
- "max": false,
- "min": false,
- "show": false,
- "total": false,
- "values": false
- },
- "lines": true,
- "linewidth": 2,
- "nullPointMode": "null",
+ "show": false
+ },
"options": {
- "alertThreshold": true
- },
- "percentage": false,
- "pluginVersion": "8.3.2",
- "pointradius": 2,
- "points": false,
- "renderer": "flot",
- "seriesOverrides": [],
- "spaceLength": 10,
- "stack": false,
- "steppedLine": false,
+ "calculate": false,
+ "calculation": {},
+ "cellGap": 2,
+ "cellValues": {},
+ "color": {
+ "exponent": 0.5,
+ "fill": "#73BF69",
+ "mode": "opacity",
+ "reverse": false,
+ "scale": "exponential",
+ "scheme": "Oranges",
+ "steps": 128
+ },
+ "exemplars": {
+ "color": "rgba(255,0,255,0.7)"
+ },
+ "filterValues": {
+ "le": 1e-9
+ },
+ "legend": {
+ "show": false
+ },
+ "rowsFrame": {
+ "layout": "auto"
+ },
+ "showValue": "never",
+ "tooltip": {
+ "mode": "single",
+ "showColorScale": false,
+ "yHistogram": false
+ },
+ "yAxis": {
+ "axisPlacement": "left",
+ "reverse": false,
+ "unit": "short"
+ }
+ },
+ "pluginVersion": "10.4.2",
+ "reverseYBuckets": false,
"targets": [
{
- "expr": "robust_entities_count{job=\"$Server\"}",
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "exemplar": true,
+ "expr": "rate(dotnet_threadpool_queue_length_bucket{server=\"$Server\"}[$__rate_interval])",
+ "format": "heatmap",
"interval": "",
- "legendFormat": "",
+ "legendFormat": "{{le}}",
+ "range": true,
"refId": "A"
}
],
- "thresholds": [],
- "timeRegions": [],
- "title": "Game Entity Count",
+ "title": "Thread Pool Queue",
"tooltip": {
- "shared": true,
- "sort": 0,
- "value_type": "individual"
- },
- "type": "graph",
- "xaxis": {
- "mode": "time",
"show": true,
- "values": []
+ "showHistogram": false
+ },
+ "type": "heatmap",
+ "xAxis": {
+ "show": true
+ },
+ "yAxis": {
+ "format": "short",
+ "logBase": 1,
+ "show": true
+ },
+ "yBucketBound": "auto"
+ },
+ {
+ "collapsed": false,
+ "gridPos": {
+ "h": 1,
+ "w": 24,
+ "x": 0,
+ "y": 71
+ },
+ "id": 88,
+ "panels": [],
+ "title": "Database",
+ "type": "row"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "palette-classic"
+ },
+ "custom": {
+ "axisBorderShow": false,
+ "axisCenteredZero": false,
+ "axisColorMode": "text",
+ "axisLabel": "",
+ "axisPlacement": "auto",
+ "barAlignment": 0,
+ "drawStyle": "line",
+ "fillOpacity": 12,
+ "gradientMode": "none",
+ "hideFrom": {
+ "legend": false,
+ "tooltip": false,
+ "viz": false
+ },
+ "insertNulls": false,
+ "lineInterpolation": "linear",
+ "lineWidth": 1,
+ "pointSize": 5,
+ "scaleDistribution": {
+ "type": "linear"
+ },
+ "showPoints": "auto",
+ "spanNulls": false,
+ "stacking": {
+ "group": "A",
+ "mode": "none"
+ },
+ "thresholdsStyle": {
+ "mode": "off"
+ }
+ },
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "green"
+ },
+ {
+ "color": "red",
+ "value": 80
+ }
+ ]
+ },
+ "unit": "ops"
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 8,
+ "w": 12,
+ "x": 0,
+ "y": 72
+ },
+ "id": 90,
+ "options": {
+ "legend": {
+ "calcs": [],
+ "displayMode": "list",
+ "placement": "bottom",
+ "showLegend": true
+ },
+ "tooltip": {
+ "mode": "single",
+ "sort": "none"
+ }
},
- "yaxes": [
+ "targets": [
{
- "$$hashKey": "object:678",
- "format": "short",
- "logBase": 1,
- "min": "0",
- "show": true
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "rate(db_write_ops{server=\"$Server\"}[$__rate_interval])",
+ "legendFormat": "Write",
+ "range": true,
+ "refId": "A"
},
{
- "$$hashKey": "object:679",
- "format": "short",
- "logBase": 1,
- "show": true
+ "datasource": {
+ "type": "prometheus",
+ "uid": "${DS_PROMETHEUS}"
+ },
+ "editorMode": "code",
+ "expr": "rate(db_read_ops{server=\"$Server\"}[$__rate_interval])",
+ "hide": false,
+ "legendFormat": "Read",
+ "range": true,
+ "refId": "B"
}
],
- "yaxis": {
- "align": false
- }
+ "title": "Database Operations",
+ "type": "timeseries"
}
],
- "refresh": false,
- "schemaVersion": 33,
- "style": "dark",
+ "refresh": "",
+ "schemaVersion": 39,
"tags": [
"game servers"
],
@@ -2823,9 +5438,9 @@ Contains the export for our Grafana dashboards at the time of writing. You will
"list": [
{
"current": {
- "selected": true,
- "text": "wizards_den_eu_west",
- "value": "wizards_den_eu_west"
+ "selected": false,
+ "text": "wizards_den_lizard",
+ "value": "wizards_den_lizard"
},
"hide": 0,
"includeAll": false,
@@ -2833,20 +5448,15 @@ Contains the export for our Grafana dashboards at the time of writing. You will
"name": "Server",
"options": [
{
- "selected": true,
+ "selected": false,
"text": "wizards_den_eu_west",
"value": "wizards_den_eu_west"
},
{
- "selected": false,
+ "selected": true,
"text": "wizards_den_lizard",
"value": "wizards_den_lizard"
},
- {
- "selected": false,
- "text": "raspberry",
- "value": "raspberry"
- },
{
"selected": false,
"text": "wizards_den_eu_west_2",
@@ -2856,9 +5466,24 @@ Contains the export for our Grafana dashboards at the time of writing. You will
"selected": false,
"text": "wizards_den_centipede",
"value": "wizards_den_centipede"
+ },
+ {
+ "selected": false,
+ "text": "leviathan",
+ "value": "leviathan"
+ },
+ {
+ "selected": false,
+ "text": "salamander",
+ "value": "salamander"
+ },
+ {
+ "selected": false,
+ "text": "vulture",
+ "value": "vulture"
}
],
- "query": "wizards_den_eu_west, wizards_den_lizard, raspberry, wizards_den_eu_west_2, wizards_den_centipede",
+ "query": "wizards_den_eu_west, wizards_den_lizard, wizards_den_eu_west_2, wizards_den_centipede, leviathan, salamander, vulture",
"queryValue": "",
"skipUrlSync": false,
"type": "custom"
@@ -2885,7 +5510,7 @@ Contains the export for our Grafana dashboards at the time of writing. You will
"timezone": "",
"title": "Perf Metrics",
"uid": "qyFqpFiGk",
- "version": 44,
+ "version": 68,
"weekStart": ""
}
```
\ No newline at end of file
From aa60285513b6fc266cf606ae57f92c401f39459c Mon Sep 17 00:00:00 2001
From: crazybrain23 <44417085+crazybrain23@users.noreply.github.com>
Date: Fri, 19 Apr 2024 05:06:21 +0100
Subject: [PATCH 17/80] Admin Banning Policy: move "IC in OOC" to metagaming
group (#201)
---
src/en/community/admin/wizards-den-banning-policy.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/en/community/admin/wizards-den-banning-policy.md b/src/en/community/admin/wizards-den-banning-policy.md
index f6c4503ea..9b2ff9666 100644
--- a/src/en/community/admin/wizards-den-banning-policy.md
+++ b/src/en/community/admin/wizards-den-banning-policy.md
@@ -114,7 +114,6 @@ Rule violations not in the offense table can still have bans applied, but have n
| Non-grouping | [Ahelp misuse in bad faith](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_abuse/ignore_the_admin-help_relay)[^badFaith] | **W** - 12hr GB | 12hr - 3d GB | **7d** - 7.5d GB | |
| Non-grouping | [Bad character name](https://wiki.spacestation14.io/wiki/Server_Rules#Act_like_a_human_being)[^requiresIntent] | **W** - 12hr GB | **12hr** - 3d GB | **7d** - 7.5d GB | |
| Metacomms | [Metacommunications](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_use_external_means_to_communicate_with_other_players_[Metacomming]) | Indef GB | | | |
-| Metacomms | [IC in OOC](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_use_outside_information_to_gain_an_advantage_[Metagaming]) | W | W - 12hr GB | 3d GB | **7d** - 7.5d GB |
| Immersion | [Text speak](https://wiki.spacestation14.io/wiki/Server_Rules#Act_like_a_human_being) | W | W | **W** - 12hr GB | W - 12hr GB |
| Immersion | [OOC terms IC](https://wiki.spacestation14.io/wiki/Server_Rules#Act_like_a_human_being)[^teachingException] | W | **W** - 12hr GB | **12hr** - 3d GB | 3d - 7.5d GB |
| Immersion | [Bypassing chat restrictions](https://wiki.spacestation14.io/wiki/Server_Rules#Act_like_a_human_being) | W | W - **4hr** - 12hr GB | 12hr - 3d GB | 3d - 7.5d GB |
@@ -132,6 +131,7 @@ Rule violations not in the offense table can still have bans applied, but have n
| Metagaming | [Metagaming round type](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_use_outside_information_to_gain_an_advantage_[Metagaming]) | W - 12hr GB | 12hr - 3d GB | 3d - 7.5d GB | |
| Metagaming | [Preemptive PDA swapping](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_use_outside_information_to_gain_an_advantage_[Metagaming]) | W | 3d - 7d RB | 7d - 15d RB | |
| Metagaming | [Preparing items not needed IC](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_pre-emptively_rush_for_weapons_and_equipment_[Powergaming]) | W | W - 12hr GB | 12hr - 3d GB | 3d - 7.5d GB |
+| Metagaming | [IC in OOC](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_use_outside_information_to_gain_an_advantage_[Metagaming]) | W | W - 12hr GB | 3d GB | **7d** - 7.5d GB |
| Competence | [Unreasonable incompetence in role](https://wiki.spacestation14.io/wiki/Server_Rules#Department_Specific_Behavior_Issues) | W - **3d** - 7d RB | 7d - 15d RB | Indef RB | |
| Competence | [Unreasonable failure of security/command to maintain order](https://wiki.spacestation14.io/wiki/Server_Rules#Command_&_Security_are_held_to_a_higher_standard) | 3d - 7d RB | 7d - 15d RB | Indef RB | |
| Competence | [Abuse of a position of authority](https://wiki.spacestation14.io/wiki/Server_Rules#Command_&_Security_are_held_to_a_higher_standard) | 3d - 7d RB | 7d - 15d RB | Indef RB | |
From 1caa67b8b3bfc0621e6c9f86cfe40fb0bb40ffee Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Sat, 20 Apr 2024 16:14:20 +0200
Subject: [PATCH 18/80] Fix git method code block
---
src/en/server-hosting/setting-up-ss14-watchdog.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/en/server-hosting/setting-up-ss14-watchdog.md b/src/en/server-hosting/setting-up-ss14-watchdog.md
index a2dc6049b..12826229c 100644
--- a/src/en/server-hosting/setting-up-ss14-watchdog.md
+++ b/src/en/server-hosting/setting-up-ss14-watchdog.md
@@ -208,10 +208,10 @@ This shouldn't apply if you're just shipping precompiled updates to the server u
SS14.Watchdog can compile and update the server when commits are pushed to a branch of the Git repository that contains the source to your fork.
-```
+```admonish info
This requires the server to have the necessary parts of the developer environment.
Also, you still need to write a Git hook or somesuch to ensure that the Watchdog is notified of the updates, or otherwise cause it to periodically check for updates.
-```admonish info
+```
```yml
From 1f220b110d5b90983648e6826088aefc5cc5d0fb Mon Sep 17 00:00:00 2001
From: Nemanja <98561806+EmoGarbage404@users.noreply.github.com>
Date: Sat, 20 Apr 2024 13:08:50 -0400
Subject: [PATCH 19/80] XenoArch Redux (3MOArch) (#191)
A proposal aiming to make XenoArch more engaging and complex and bring
it up to the high standards established by Anomalies.
Primarily focuses on a modification of how artifact nodes, activation,
and research works. Additionally includes proposal for new machines and
ways of interacting with artifacts.
---
src/SUMMARY.md | 1 +
src/en/proposals/emogarbage-xenoarch-redux.md | 173 ++++++++++++++++++
2 files changed, 174 insertions(+)
create mode 100644 src/en/proposals/emogarbage-xenoarch-redux.md
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 682fbcb32..807a2e888 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -136,6 +136,7 @@ Design Proposals
- [Security Genpop Rework](en/proposals/ike709-genpop-security.md)
- [Rogue Drones](en/proposals/mirrorcult-rogue-drones.md)
- [Game Director](en/proposals/tomleys-game-director.md)
+- [XenoArch Redux (3moArch)](en/proposals/emogarbage-xenoarch-redux.md)
- [Grid Inventory](en/proposals/emogarbage-grid-inventory.md)
- [Atmos Roadmap](en/proposals/notafet-atmos.md)
- [Cleanup Crew](en/proposals/mirrorcult-cleanup-crew-gamemode.md)
diff --git a/src/en/proposals/emogarbage-xenoarch-redux.md b/src/en/proposals/emogarbage-xenoarch-redux.md
new file mode 100644
index 000000000..a14c08051
--- /dev/null
+++ b/src/en/proposals/emogarbage-xenoarch-redux.md
@@ -0,0 +1,173 @@
+# XenoArch Redux [3MOArch]
+
+| Designers | Implemented | GitHub Links |
+|-----------------|---|---|
+| Thee EmoGarbage | :x: No | TBD |
+
+## Overview
+
+This proposal aims to re-imagine the science subdepartment of XenoArch and Artifacts in general in an effort to give them more depth, and utility.
+This will be accomplished by changing node traversal to add more player agency, improving in-game tools for categorizing and understanding artifact structure, and adding additional equipment that makes manipulation more interesting.
+
+The ultimate goal is to redesign the system so players can better understand how artifacts work and to allow greater utility and mechanics to arise out of artifacts.
+XenoArch should feel like unlocking the sprawling secrets of an artifact while additionally gaining points as a secondary reward for the research.
+
+_This redesign lends partial inspiration to Goon's artlab as well as Noita's customizable wands._
+
+## Background
+As it is now, artifacts consist of interconnected nodes, each one carrying an effect and a trigger.
+The effect is just some crazy behavior that happens in response to the trigger, which is just some kind of generic action taken upon the artifact.
+
+These nodes form a tree, wherein each individual node's depth within this tree determines the craziness of the its effect and trigger.
+An artifact has a single node which is active, which is what determines the current effect and trigger which must be done.
+
+Moving to another node requires the completion of the current node's trigger and is semi-random in nature.
+
+While the core concept of XenoArch is interesting and has decent integration with salvage and cooperation for collecting tools for triggers, there are also many situations where players feel as if they lose the ability to meaningfully interact with them.
+
+I'll outline some of the core issues here:
+
+### Randomness
+Artifact generation is completely random, but so is the activation of effects.
+Players cannot meaningfully control which effects they activate and even the limited tools they have like the traversal distorter are extremely esoteric and don't actually provide meaningful control.
+
+The result of this is that while many effects could potentially be extremely useful and provide players interesting means of interacting with their environments, there's no way to actually harness of control the randomness to produce those interesting outcomes.
+At best, you simply re-trigger a beneficial effect several times and reap the rewards in that way.
+
+### Lack of Complexity
+Artifacts are primarily dictated by a single effect with the occasional mix-up of having permanent effects (many of which are underwhelming).
+Activation stimuli are similar: the only sliding scale to adjust with how difficult something is to activate is just how hard it is to do that singular trigger.
+
+Since these triggers are always placed in isolation, unless the effect is having some pronounced impact on the crew's ability to trigger the artifact, triggers mostly devolve into incredibly simple and routine tasks.
+
+A water trigger should have lots of depth, but it instead is mostly just walking in with a cup of water and splashing it, which is really the most boring way to engage with something like that.
+
+### Lack of Progression
+Artifacts have an innate progression in the form of the scaling of nodes, which is mostly built around increasingly difficult triggers and more dangerous and wacky effects.
+This is a good start for a system like this, but the unfortunate reality of it is that the scaling isn't pronounced enough to often feel like a deviation from the early-depth nodes.
+
+Especially when taken in with randomization of artifacts, you can oftentimes just get subpar generation that flounders in weak effects that don't feel like a progression in research.
+
+## Artifacts
+I'll use the element of a [tech tree](https://en.wikipedia.org/wiki/Technology_tree) as a reference to explain the new generation.
+
+Each node is essentially an upgrade in a tech tree.
+The structure can be described as a typical tech tree structure (a [directed acyclic graph](https://en.wikipedia.org/wiki/Directed_acyclic_graph)) but without the presence of the first element in the graph.
+
+Just like the current system, all of these nodes have a trigger and an effect associated with them.
+However, you do not 'move' to a node like the current system, but you instead permanently unlock it like a tech tree.
+
+And just like a tech tree, unlocking a node has a cost associated with it.
+The 'cost' is the activation of all of the triggers of the nodes in that path--that is, all of the nodes that needed to be unlocked in order for the current node to become available.
+
+In this situation, the 'active' nodes are the nodes in each path that have the highest tier.
+These are the nodes that will produce effects when they are activated.
+The remaining nodes are classified as 'latent'--unlocked but not creating any effects when the artifact is activated.
+
+All remaining nodes are simply locked and have no behavior.
+
+### Activation and Unlocking Nodes
+The activation of an artifact is now something that is distinct from simply triggering a node in the old system.
+
+Activating an artifact is simply achieved by using it in hand, clicking on something, or other context interactions.
+Doing this simply causes all the effects of the active nodes simultaneously.
+
+By making many effects happen at once, they can combine in novel ways and increase the utility and chaos of the artifact, greatly improving on the current system where lackluster nodes can seem to have 0 effect at all.
+
+As a balancing factor, each node of the artifact now has a durability.
+Activating an artifact degrades the durability of all of the active nodes.
+When the node is fully degraded, it no longer produces any effect when activated.
+
+The durability can be repaired using special equipment (which will be elaborated on further later).
+
+In exchange easier activation, unlocking nodes is now more complex.
+To unlock a node, you must provide the stimulus for that node as well as the the stimuli for every node below it in its path (the path being all of the nodes that had to be unlocked in order to reach the current node).
+
+Once the first stimulus is provided, an activation period (roughly 10 seconds) begins wherein all the stimuli activations will be recorded.
+At the end of that period, if the stimuli recorded _exactly match_ a node's required stimuli, it will be unlocked.
+
+```admonish info
+Note that if you need stimuli A, B, and C but you instead provide A, B, C, and X, the node will not be unlocked.
+It must be an exact match and not simply a superset.
+```
+
+Once unlocked, the node's effect will occur while a small animation and sound effect playing, giving feedback to the players that something has occured.
+
+## Equipment
+
+### Analysis Console
+The artifact analyzer and analysis console will be improved to no longer have any kind of delay and to show significantly more information
+
+The console UI will now visually draw all the nodes in the structure, using lines to connect them.
+All unlocked nodes will have basic information such as stimuli, effects, depth, research value, durability, and whether or not the node is active.
+This info can be accessed by clicking on the node in the UI, which will show a small window.
+
+Locked nodes that are connected to unlocked nodes will be given a limited information display, showing only the stimuli and the effect.
+This allows players to have a limited strategy for the nodes they want to unlock.
+
+### Handheld Scanner
+The handheld node scanner will be used to check information on the current active nodes of the artifact.
+
+Clicking on an artifact with the handheld scanner will take a "snapshot" of it which can be viewed in a UI.
+This gives similar info as the analysis console but is limited to the active nodes of the artifact.
+
+The scanner now gains a lot of utility as being able to quickly assess the state of an artifact without needing to bring it to science.
+Being able to check the durability also helps when actively using the effects on the go.
+
+The scanner also has the ability to view the node structure of artifact fragments, which can be useful for sifting through them when trying to splice artifacts.
+
+### Artifexium
+Artifexium, which previously activated artifacts, will now serve as a "dummy" stimuli when applied during an activation period.
+
+For example, if stimuli A, B, and C are needed, but only A and B are provided, spraying artifexium will substitute the non-existent C stimulus and unlock the node.
+
+If there are multiple nodes which could be unlocked by a the artifexium (say, a node needing stimuli ABC and one needing stimuli ABD), one will simply be unlocked at random.
+
+### Artifact Fragments
+Artifact fragments will no longer simply just be a random chunk that's spit out after an artifact is crushed.
+Instead, each distinct path of the artifact's structure will be turned into a fragment which stores the nodes and connections from that path.
+
+These fragments, instead of being crafted into a new artifact, will be combined with existing artifacts at a **Splicer**.
+This provides interesting gameplay where you can combine artifacts to create more tactically useful artifacts with beneficial or dangerous effects.
+
+The fragments will also scale their artifexium values in relation to the amount research they provide.
+
+### New Equipment
+New equipment (besides the splicer) will focus mostly on manipulating the active nodes of an artifact and interacting with the new mechanics.
+
+**Artifact Glue** is a reagent made from artifexium and when applied to an artifact will repair the durability of nodes on it.
+This provides additional uses for artifexium and ways to extend an artifact's lifespan in the case of beneficial effects that players are using often.
+
+The **Resequencer** simply takes the existing nodes and shuffles them, creating new connections.
+This can completely flip the effects of an artifact and enable new wacky combinations.
+It can also help reach particularly hard to get nodes and allow science to fully unlock the artifact.
+
+The **Arti-nUKer** is a special device that obliterates all active nodes on an artifact.
+The severed connections are automatically merged, fixing any holes created in the structure.
+This is basically a free re-roll of effects paired with easier to activate high-depth nodes.
+
+The Resequencer and Arti-nUKer both serve as mid-tier research to provide optional depth for the truly engaged archeologists, without the boring technical complexity of the traversal distorter.
+
+## Research Generation
+The analysis console UI will show the current research value of the artifact as well as the value it needs to exceed to generate more research.
+
+This will also show the calculation for how the research value is achieved, providing more info and transparency to players.
+
+The research value for an artifact is calculated similarly to how it is now:
+- Unlocked nodes give research based on their effect, stimulus, and depth.
+- Artifacts with no locked nodes grant an additional bonus.
+
+However, there are factors which can damage the research value of an artifact:
+- Nodes with completely degraded durability (gluing the artifact to repair it does not incur this penalty)
+- Missing nodes, such as those from the effect of the Arti-nUKer.
+- Additional nodes, such as from the effects of the Splicer.
+
+Note that the calculation for the last two points is based on the total number of nodes in the original vs. the current artifact.
+If you destroy 2 nodes and then repair it by splicing 2 nodes onto it, you incur 0 penalty.
+
+To actually gain research from the artifact, you must place it on an analyzer and begin the 'research' task in the analysis console UI.
+This begins a 30 second countdown where the artifact must remain on the analyzer, cannot be activated, cannot have any stimuli trigger, and the analyzer must remain powered.
+
+This provides an interesting window wherein sabotage and other such measures can be taken to steal the artifact or otherwise interrupt science.
+
+At the end of this countdown, the research is added into the server and a glorious sound effect plays.
\ No newline at end of file
From d4d801727ab0d38649ce46fe2a360446f5ec92aa Mon Sep 17 00:00:00 2001
From: Jezithyr
Date: Sat, 20 Apr 2024 20:13:16 -0700
Subject: [PATCH 20/80] Game-Area documentation overhaul, Work Groups and
Maintainer/Review Policy (#199)
The biggest change here is separating game (SS14) documentation into
Game Areas to better categorize mechanics/docs and make it easier to
find things.
Game Areas are separated into Global and Department areas:
- A Global Area is a part of the game that does not fit under a single
department or is specific to the individual player's experience. These
may also be high-level concepts related to the game. (For example: UI,
Art, Mapping, Species, etc.)
- A Department Area is a part of the game that fits the design/theme of
a specific in-game department. (For Example: Security, Atmospherics,
Command, etc.)
This PR also implements workgroups as a concept (Code-Owners but for
Game Design). A workgroup is an opt-in/opt-out role that is responsible
for maintaining the documentation, design, and PR Guidelines of a Game
Area. Maintainers can be a part of multiple workgroups or none if they
so choose.
Additionally, this PR will define policy for PR reviews, specifically
going over the review process and what is required to approve/merge a
PR. Along with a list of guidelines for contributors to look through to
help speed up the review process. This also includes a Maintainer policy
document that outlines the powers/expectations that the maintainer role
entails, how maintainers are chosen, and what contributors should do if
they want to become a maintainer someday.
---
.github/CODEOWNERS | 1 -
src/SUMMARY.md | 86 ++++++++++++++-----
src/en/community/maintainer.md | 3 +
.../wizards-den-maintainer-policy.md | 5 ++
.../maintainer/wizards-den-review-policy.md | 5 ++
.../general-development/feature-proposals.md | 4 +-
.../expected-feature-proposal-decorum.md | 2 +-
src/en/general-development/work-groups.md | 57 ++++++++++++
src/en/proposals/notafet-atmos.md | 2 +-
.../areas/core/accessibility.md | 5 ++
.../areas/core/accessibility/guidelines.md | 5 ++
.../areas/core/admin-tools.md | 5 ++
.../areas/core/admin-tools/guidelines.md | 5 ++
src/en/space-station-14/areas/core/art.md | 5 ++
.../{ => areas/core/art}/displacement-maps.md | 0
.../areas/core/art/guidelines.md | 5 ++
.../core/character-species/guidelines.md | 5 ++
.../areas/core/characters-species.md | 5 ++
src/en/space-station-14/areas/core/combat.md | 5 ++
.../{ => areas/core/combat}/destructible.md | 0
.../areas/core/combat/guidelines.md | 5 ++
src/en/space-station-14/areas/core/mapping.md | 5 ++
.../{ => areas/core/mapping}/dungeons.md | 2 +-
.../core/mapping/guidelines.md} | 35 +++++++-
.../core/mapping/guides/general-guide.md} | 6 +-
.../areas/core/player-interaction.md | 8 ++
.../player-interaction}/cartridge-loaders.md | 0
.../core/player-interaction/guidelines.md | 5 ++
.../areas/core/roleplay-lore.md | 5 ++
.../areas/core/roleplay-lore/guidelines.md | 5 ++
.../space-station-14/areas/core/round-flow.md | 5 ++
.../core/round-flow}/antagonists.md | 0
.../areas/core/round-flow/guidelines.md | 5 ++
.../{ => areas/core/round-flow}/npcs.md | 0
.../areas/core/user-interface.md | 5 ++
.../areas/core/user-interface/guidelines.md | 5 ++
src/en/space-station-14/areas/departments.md | 6 ++
.../areas/departments/atmos.md | 5 ++
.../areas/departments/atmos/guidelines.md | 5 ++
.../areas/departments/cargo-salvage.md | 5 ++
.../departments/cargo-salvage/guidelines.md | 5 ++
.../areas/departments/command.md | 5 ++
.../areas/departments/command/guidelines.md | 5 ++
.../areas/departments/engineering.md | 5 ++
.../departments/engineering}/construction.md | 0
.../engineering}/device-network.md | 0
.../departments/engineering/guidelines.md | 5 ++
.../departments/engineering}/node-networks.md | 0
.../departments/engineering}/pow3r.md | 0
.../areas/departments/medical.md | 5 ++
.../areas/departments/medical/guidelines.md | 5 ++
.../areas/departments/science.md | 5 ++
.../departments/science}/chemistry.md | 0
.../science}/chemistry/metabolism.md | 0
.../science}/chemistry/reactions.md | 0
.../science}/chemistry/reagents.md | 0
.../science}/chemistry/solution-containers.md | 0
.../areas/departments/science/guidelines.md | 5 ++
.../areas/departments/security.md | 5 ++
.../areas/departments/security/guidelines.md | 5 ++
.../areas/departments/service.md | 5 ++
.../areas/departments/service/guidelines.md | 5 ++
.../principles.md => design-principles.md} | 0
.../{core-design.md => design.md} | 8 +-
.../space-station-14/mapping/mapping-sins.md | 23 -----
.../introduction-to-ss14-by-example.md | 2 +-
src/en/templates/legacy.md | 3 +
src/index.md | 4 +-
68 files changed, 366 insertions(+), 66 deletions(-)
create mode 100644 src/en/community/maintainer.md
create mode 100644 src/en/community/maintainer/wizards-den-maintainer-policy.md
create mode 100644 src/en/community/maintainer/wizards-den-review-policy.md
create mode 100644 src/en/general-development/work-groups.md
create mode 100644 src/en/space-station-14/areas/core/accessibility.md
create mode 100644 src/en/space-station-14/areas/core/accessibility/guidelines.md
create mode 100644 src/en/space-station-14/areas/core/admin-tools.md
create mode 100644 src/en/space-station-14/areas/core/admin-tools/guidelines.md
create mode 100644 src/en/space-station-14/areas/core/art.md
rename src/en/space-station-14/{ => areas/core/art}/displacement-maps.md (100%)
create mode 100644 src/en/space-station-14/areas/core/art/guidelines.md
create mode 100644 src/en/space-station-14/areas/core/character-species/guidelines.md
create mode 100644 src/en/space-station-14/areas/core/characters-species.md
create mode 100644 src/en/space-station-14/areas/core/combat.md
rename src/en/space-station-14/{ => areas/core/combat}/destructible.md (100%)
create mode 100644 src/en/space-station-14/areas/core/combat/guidelines.md
create mode 100644 src/en/space-station-14/areas/core/mapping.md
rename src/en/space-station-14/{ => areas/core/mapping}/dungeons.md (97%)
rename src/en/space-station-14/{mapping/mapping-checklist.md => areas/core/mapping/guidelines.md} (91%)
rename src/en/space-station-14/{mapping.md => areas/core/mapping/guides/general-guide.md} (98%)
create mode 100644 src/en/space-station-14/areas/core/player-interaction.md
rename src/en/space-station-14/{ => areas/core/player-interaction}/cartridge-loaders.md (100%)
create mode 100644 src/en/space-station-14/areas/core/player-interaction/guidelines.md
create mode 100644 src/en/space-station-14/areas/core/roleplay-lore.md
create mode 100644 src/en/space-station-14/areas/core/roleplay-lore/guidelines.md
create mode 100644 src/en/space-station-14/areas/core/round-flow.md
rename src/en/space-station-14/{core-design => areas/core/round-flow}/antagonists.md (100%)
create mode 100644 src/en/space-station-14/areas/core/round-flow/guidelines.md
rename src/en/space-station-14/{ => areas/core/round-flow}/npcs.md (100%)
create mode 100644 src/en/space-station-14/areas/core/user-interface.md
create mode 100644 src/en/space-station-14/areas/core/user-interface/guidelines.md
create mode 100644 src/en/space-station-14/areas/departments.md
create mode 100644 src/en/space-station-14/areas/departments/atmos.md
create mode 100644 src/en/space-station-14/areas/departments/atmos/guidelines.md
create mode 100644 src/en/space-station-14/areas/departments/cargo-salvage.md
create mode 100644 src/en/space-station-14/areas/departments/cargo-salvage/guidelines.md
create mode 100644 src/en/space-station-14/areas/departments/command.md
create mode 100644 src/en/space-station-14/areas/departments/command/guidelines.md
create mode 100644 src/en/space-station-14/areas/departments/engineering.md
rename src/en/space-station-14/{ => areas/departments/engineering}/construction.md (100%)
rename src/en/space-station-14/{ => areas/departments/engineering}/device-network.md (100%)
create mode 100644 src/en/space-station-14/areas/departments/engineering/guidelines.md
rename src/en/space-station-14/{ => areas/departments/engineering}/node-networks.md (100%)
rename src/en/space-station-14/{ => areas/departments/engineering}/pow3r.md (100%)
create mode 100644 src/en/space-station-14/areas/departments/medical.md
create mode 100644 src/en/space-station-14/areas/departments/medical/guidelines.md
create mode 100644 src/en/space-station-14/areas/departments/science.md
rename src/en/space-station-14/{ => areas/departments/science}/chemistry.md (100%)
rename src/en/space-station-14/{ => areas/departments/science}/chemistry/metabolism.md (100%)
rename src/en/space-station-14/{ => areas/departments/science}/chemistry/reactions.md (100%)
rename src/en/space-station-14/{ => areas/departments/science}/chemistry/reagents.md (100%)
rename src/en/space-station-14/{ => areas/departments/science}/chemistry/solution-containers.md (100%)
create mode 100644 src/en/space-station-14/areas/departments/science/guidelines.md
create mode 100644 src/en/space-station-14/areas/departments/security.md
create mode 100644 src/en/space-station-14/areas/departments/security/guidelines.md
create mode 100644 src/en/space-station-14/areas/departments/service.md
create mode 100644 src/en/space-station-14/areas/departments/service/guidelines.md
rename src/en/space-station-14/{core-design/principles.md => design-principles.md} (100%)
rename src/en/space-station-14/{core-design.md => design.md} (94%)
delete mode 100644 src/en/space-station-14/mapping/mapping-sins.md
create mode 100644 src/en/templates/legacy.md
diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
index 2371772eb..3e844e8af 100644
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@@ -5,5 +5,4 @@
/src/en/templates/ @moonheart08
/src/en/proposals/ @jezithyr
/src/en/templates/ @jezithyr
-/src/en/space-station-14/core-design @jezithyr
/src/ru/* @ficcialfaint
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 807a2e888..dc2c7be58 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -36,8 +36,7 @@ General Development
- [YAML Crash Course](en/general-development/tips/yaml-crash-course.md)
- [Feature Proposals](en/general-development/feature-proposals.md)
- [Expected Team Decorum & Usage](en/general-development/feature-proposals/expected-feature-proposal-decorum.md)
- - [Core Game Design](en/space-station-14/core-design.md)
-
+- [Work Groups](en/general-development/work-groups.md)
SS14 By Example
===============
@@ -99,26 +98,66 @@ Space Station 14
================
----------------------
-- [Core Game Design](en/space-station-14/core-design.md)
- - [Design Principles](en/space-station-14/core-design/principles.md)
- - [Antagonists](en/space-station-14/core-design/antagonists.md)
-- [Mapping](en/space-station-14/mapping.md)
- - [Mapping Checklist](en/space-station-14/mapping/mapping-checklist.md)
- - [Mapping Sins](en/space-station-14/mapping/mapping-sins.md)
-- [Chemistry](en/space-station-14/chemistry.md)
- - [Solution Containers](en/space-station-14/chemistry/solution-containers.md)
- - [Reagents](en/space-station-14/chemistry/reagents.md)
- - [Metabolism](en/space-station-14/chemistry/metabolism.md)
- - [Reactions](en/space-station-14/chemistry/reactions.md)
-- [Construction](en/space-station-14/construction.md)
-- [Destructible](en/space-station-14/destructible.md)
-- [Device Network](en/space-station-14/device-network.md)
-- [Pow3r](en/space-station-14/pow3r.md)
-- [Cartridge Loaders](en/space-station-14/cartridge-loaders.md)
-- [Node Networks](en/space-station-14/node-networks.md)
-- [Dungeons](en/space-station-14/dungeons.md)
-- [NPCs](en/space-station-14/npcs.md)
-- [Displacement Maps](en/space-station-14/displacement-maps.md)
+
+- [Design](en/space-station-14/design.md)
+ - [Design Principles](en/space-station-14/design-principles.md)
+- [Game Areas]()
+ - [Global]()
+ - [Accessibility](en/space-station-14/areas/core/accessibility.md)
+ - [PR Guidelines](en/space-station-14/areas/core/accessibility/guidelines.md)
+ - [Admin Tooling](en/space-station-14/areas/core/admin-tools.md)
+ - [PR Guidelines](en/space-station-14/areas/core/admin-tools/guidelines.md)
+ - [Art](en/space-station-14/areas/core/art.md)
+ - [PR Guidelines](en/space-station-14/areas/core/art/guidelines.md)
+ - [Displacement Maps](en/space-station-14/areas/core/art/displacement-maps.md)
+ - [Character/Species](en/space-station-14/areas/core/characters-species.md)
+ - [PR Guidelines](en/space-station-14/areas/core/character-species/guidelines.md)
+ - [Combat](en/space-station-14/areas/core/combat.md)
+ - [PR Guidelines](en/space-station-14/areas/core/combat/guidelines.md)
+ - [Destructible](en/space-station-14/areas/core/combat/destructible.md)
+ - [Mapping](en/space-station-14/areas/core/mapping.md)
+ - [PR Guidelines](en/space-station-14/areas/core/mapping/guidelines.md)
+ - [Dungeons](en/space-station-14/areas/core/mapping/dungeons.md)
+ - [Guides]()
+ - [General Guide](en/space-station-14/areas/core/mapping/guides/general-guide.md)
+
+ - [Player Interaction](en/space-station-14/areas/core/player-interaction.md)
+ - [PR Guidelines](en/space-station-14/areas/core/player-interaction/guidelines.md)
+ - [Roleplay/Lore](en/space-station-14/areas/core/roleplay-lore.md)
+ - [PR Guidelines](en/space-station-14/areas/core/roleplay-lore/guidelines.md)
+ - [Roundflow](en/space-station-14/areas/core/round-flow.md)
+ - [PR Guidelines](en/space-station-14/areas/core/round-flow/guidelines.md)
+ - [Antagonists](en/space-station-14/areas/core/round-flow/antagonists.md)
+ - [User Interface](en/space-station-14/areas/core/user-interface.md)
+ - [PR Guidelines](en/space-station-14/areas/core/user-interface/guidelines.md)
+
+
+ - [Departments](en/space-station-14/areas/departments.md)
+ - [Atmos](en/space-station-14/areas/departments/atmos.md)
+ - [PR Guidelines](en/space-station-14/areas/departments/atmos/guidelines.md)
+ - [Cargo/Salvage](en/space-station-14/areas/departments/cargo-salvage.md)
+ - [PR Guidelines](en/space-station-14/areas/departments/cargo-salvage/guidelines.md)
+ - [Command](en/space-station-14/areas/departments/command.md)
+ - [PR Guidelines](en/space-station-14/areas/departments/command/guidelines.md)
+ - [Engineering](en/space-station-14/areas/departments/engineering.md)
+ - [PR Guidelines](en/space-station-14/areas/departments/engineering/guidelines.md)
+ - [Construction](en/space-station-14/areas/departments/engineering/construction.md)\
+ - [Node Networks](en/space-station-14/areas/departments/engineering/node-networks.md)
+ - [Device Network](en/space-station-14/areas/departments/engineering/device-network.md)
+ - [Pow3r](en/space-station-14/areas/departments/engineering/pow3r.md)
+ - [Medical](en/space-station-14/areas/departments/medical.md)
+ - [PR Guidelines](en/space-station-14/areas/departments/medical/guidelines.md)
+ - [Science](en/space-station-14/areas/departments/science.md)
+ - [PR Guidelines](en/space-station-14/areas/departments/science/guidelines.md)
+ - [Chemistry](en/space-station-14/areas/departments/science/chemistry.md)
+ - [Metabolism](en/space-station-14/areas/departments/science/chemistry/metabolism.md)
+ - [Reactions](en/space-station-14/areas/departments/science/chemistry/reactions.md)
+ - [Reagents](en/space-station-14/areas/departments/science/chemistry/reagents.md)
+ - [Solution Containers](en/space-station-14/areas/departments/science/chemistry/solution-containers.md)
+ - [Security](en/space-station-14/areas/departments/security.md)
+ - [PR Guidelines](en/space-station-14/areas/departments/security/guidelines.md)
+ - [Service](en/space-station-14/areas/departments/service.md)
+ - [PR Guidelines](en/space-station-14/areas/departments/service/guidelines.md)
Design Proposals
================
@@ -194,6 +233,9 @@ Community
- [Space Wizards Role Hierarchy](en/community/space-wizards-role-hierarchy.md)
- [Space Wizards Maintainer List](en/community/space-wizards-maintainer-list.md)
- [Discord Rich Presence Repository](en/community/discord-rich-presence-repository.md)
+- [Maintainer](en/community/maintainer.md)
+ - [Maintainer Policy](en/community/maintainer/wizards-den-maintainer-policy.md)
+ - [Review Policy](en/community/maintainer/wizards-den-review-policy.md)
- [Admin](en/community/admin.md)
- [Admin Tooling](en/community/admin/admin-tooling.md)
- [Admin Command Cookbook](en/community/admin/admin-tooling/admin-command-cookbook.md)
diff --git a/src/en/community/maintainer.md b/src/en/community/maintainer.md
new file mode 100644
index 000000000..ad40646de
--- /dev/null
+++ b/src/en/community/maintainer.md
@@ -0,0 +1,3 @@
+# Maintainer
+
+This section contains information on Maintaier and PR-Review Policies, **as it pertains to Wizards Den servers, hosted by Space Wizards.** These policies do not apply to other servers, and may be waived in exceptional circumstances.
\ No newline at end of file
diff --git a/src/en/community/maintainer/wizards-den-maintainer-policy.md b/src/en/community/maintainer/wizards-den-maintainer-policy.md
new file mode 100644
index 000000000..2d68c8c98
--- /dev/null
+++ b/src/en/community/maintainer/wizards-den-maintainer-policy.md
@@ -0,0 +1,5 @@
+# Wizards Den Maintainer Policy
+
+```admonish warning "Work in Progress"
+This page is a work in progress! Maintainer policy will be posted when they are ready.
+```
\ No newline at end of file
diff --git a/src/en/community/maintainer/wizards-den-review-policy.md b/src/en/community/maintainer/wizards-den-review-policy.md
new file mode 100644
index 000000000..16e8c3dc1
--- /dev/null
+++ b/src/en/community/maintainer/wizards-den-review-policy.md
@@ -0,0 +1,5 @@
+# Wizards Den Review Policy
+
+```admonish warning "Work in Progress"
+This page is a work in progress! Review policy will be posted when they are ready.
+```
\ No newline at end of file
diff --git a/src/en/general-development/feature-proposals.md b/src/en/general-development/feature-proposals.md
index cdee7ce77..3943e2210 100644
--- a/src/en/general-development/feature-proposals.md
+++ b/src/en/general-development/feature-proposals.md
@@ -6,7 +6,7 @@ If you are considering adding or reworking some major component of the game it's
1. Make a copy of the design proposal template located at `src/en/templates/proposal.md`.
-3. Read through [SS14's Core Design Documentation](../space-station-14/core-design.md) (for gameplay-related proposals).
+3. Read through [SS14's Core Design Documentation](../space-station-14/design.md) (for gameplay-related proposals).
4. Write your proposal (see [guide to editing docs](../meta/guide-to-editing-docs.md)).
@@ -46,7 +46,7 @@ A good rule of thumb if the new feature or rework you have in mind would require
No idea! What design proposals do or do not get in is determined by maintainer approval like normal PRs. If you can get at least one maint to decide that it sounds like a good idea then there's a good chance that it will get accepted. Pretty much any idea is going to need at least some critiquing before it gets merged so don't get discouraged!
``` admonish tip "Design Principles"
-If you want to improve your chances, it's recommended that you read the [SS14 Core Design Documentation](/src/en/space-station-14/core-design.md) document to get a high-level overview before you start writing, as it'll provide context for why things are the way they are.
+If you want to improve your chances, it's recommended that you read the [SS14 Core Design Documentation](/src/en/space-station-14/design.md) document to get a high-level overview before you start writing, as it'll provide context for why things are the way they are.
PR'd design documents should also follow the [Decorum Guidelines](./feature-proposals/expected-feature-proposal-decorum.md).
```
diff --git a/src/en/general-development/feature-proposals/expected-feature-proposal-decorum.md b/src/en/general-development/feature-proposals/expected-feature-proposal-decorum.md
index 53fd59b99..6f903f66b 100644
--- a/src/en/general-development/feature-proposals/expected-feature-proposal-decorum.md
+++ b/src/en/general-development/feature-proposals/expected-feature-proposal-decorum.md
@@ -8,7 +8,7 @@
Any documents proposed:
-- Should conform to the basic [Core Game Design](../../space-station-14/core-design.md) as well as this document obviously.
+- Should conform to the basic [Core Game Design](../../space-station-14/design.md) as well as this document obviously.
- Should contain sufficient justification for their existence,
- Can be closed or drafted at maintainer discretion,
- Are a reflection of SS14 to others that may be interested in how the game is designed. Take note of that.
diff --git a/src/en/general-development/work-groups.md b/src/en/general-development/work-groups.md
new file mode 100644
index 000000000..e8a87aca5
--- /dev/null
+++ b/src/en/general-development/work-groups.md
@@ -0,0 +1,57 @@
+Work Groups
+=====================
+Work-groups are effectively the design equivalent to Code-Owners. Each work group is made up from maintainers that volunteer to upkeep the documentation and guidelines related to that area of the game. If you have a question about something related to one of the department/game areas feel free to message a member of its work group to get an authoritative answer.
+
+Each work group is responsible for maintaining corresponding design and pr guidelines documents in the docs repo that outlines the current and intended design for that game area, along with what is acceptible design/quality for a PR in that game area. Maintainers that are not part of any work groups are generalists, and while they might not be fully up to date with the design of a game-area they can still help answer questions.
+
+
+## Maintainer work groups:
+This list is updated less than discord/github, for a more accurate list look at the github work-group teams or discord roles.
+
+### Game-Wide
+- [Accessibility:](../space-station-14/areas/core/accessibility.md)\
+ Bhijn & Myr(deathride58), AJCM
+- [Admin Tooling:](../space-station-14/areas/core/admin-tools.md)\
+ Jezithyr, Chief-Engineer, Vasilis, Julian, Bhijn & Myr(deathride58)
+- [Art:](../space-station-14/areas/core/art.md)\
+ EmoGarbage, Flareguy
+- [Character/Species:](../space-station-14/areas/core/characters-species.md)\
+ Jezithyr, Lank, Vasilis, KeronSHB, Bhijn & Myr(deathride58), AJCM
+- [Combat:](../space-station-14/areas/core/combat.md)\
+ Jezithyr, EmoGarbage, AJCM, KeronSHB, Bhijn & Myr(deathride58)
+- [Player Interaction:](../space-station-14/areas/core/player-interaction.md)\
+
+- [Mapping:](../space-station-14/areas/core/mapping.md)\
+ Emmise
+- [Roleplay/Lore:](../space-station-14/areas/core/roleplay-lore.md)\
+ Lank, KeronSHB, Vasilis
+- [Round Flow:](../space-station-14/areas/core/round-flow.md)\
+ Jezithyr, EmoGarbage, Tayrthan, KeronSHB, Bhijn & Myr(deathride58), AJCM
+- [User Interface:](../space-station-14/areas/core/user-interface.md)\
+ Jezithyr, EmoGarbage, AJCM, Julian, Bhijn & Myr(deathride58)
+
+### Departments
+- [Atmos:](../space-station-14/areas/departments/atmos.md)\
+ Jezithyr, KeronSHB, NotAFet(PartMedia)
+- [Cargo/Salvage:](../space-station-14/areas/departments/cargo-salvage.md)\
+
+- [Command:](../space-station-14/areas/departments/command.md)\
+ KeronSHB, EmoGarbage, Vasilis
+- [Engineering:](../space-station-14/areas/departments/engineering.md)\
+ Jezithyr, Julian, AJCM, KeronSHB
+- [Medical:](../space-station-14/areas/departments/medical.md)\
+ Jezithyr, Vasilis, AJCM,
+- [Science:](../space-station-14/areas/departments/science.md)\
+ Jezithyr, EmoGarbage, AJCM, Tayrtahn
+- [Security:](../space-station-14/areas/departments/security.md)\
+ Lank(LankLTE), KeronSHB
+- [Service:](../space-station-14/areas/departments/service.md)\
+ AJCM, Tayrtahn, NotAFet(PartMedia)
+
+## For maintainers:
+
+Work-groups are non exclusive, you can be in as many or as few as you want, however you should expect to be able to answer questions and be involved in the design of the area's that you have selected.
+
+If you are not in a pr's associated work-group you can still review the PR, however you should make sure to read the relevant design documentation and PR guidelines before doing a review. Ideally, you should leave associated PRs to be reviewed by their work-group members, but it's fine to merge something as long as it fits the design and meets the guidelines.
+
+If you plan on being involved with a workgroup for a long time, please add yourself to the above list. Likewise, if you are on the list and leave the workgroup with no intention of returning to it, you should remove yourself from the list.
\ No newline at end of file
diff --git a/src/en/proposals/notafet-atmos.md b/src/en/proposals/notafet-atmos.md
index d9f3ebff5..1f3b2f870 100644
--- a/src/en/proposals/notafet-atmos.md
+++ b/src/en/proposals/notafet-atmos.md
@@ -12,7 +12,7 @@ Most atmos players currently agree that atmos is not very fun to play, for some
2. Atmos can't actually rectify atmos problems in a reasonable amount of time. For example, if there actually is a plasma leak, scrubbers typically work too slowly resulting in the plasma inevitably being lit before it can be cleaned up.
-3. Atmos techs don't play with the rest of the station, preferring to isolate themselves to produce a funny green gas that is only particularly useful for shuttle bombing. Mechanics like this violate the [fundamental design principles](../space-station-14/core-design.md). While these mechanics shouldn't be removed per-se, more focus should be given to mechanics that increase interactions with the station, like making sure the air is breathable and well-heated.
+3. Atmos techs don't play with the rest of the station, preferring to isolate themselves to produce a funny green gas that is only particularly useful for shuttle bombing. Mechanics like this violate the [fundamental design principles](../space-station-14/design.md). While these mechanics shouldn't be removed per-se, more focus should be given to mechanics that increase interactions with the station, like making sure the air is breathable and well-heated.
## Proposal
diff --git a/src/en/space-station-14/areas/core/accessibility.md b/src/en/space-station-14/areas/core/accessibility.md
new file mode 100644
index 000000000..c67b651d0
--- /dev/null
+++ b/src/en/space-station-14/areas/core/accessibility.md
@@ -0,0 +1,5 @@
+# Accessibility
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/core/accessibility/guidelines.md b/src/en/space-station-14/areas/core/accessibility/guidelines.md
new file mode 100644
index 000000000..e78a7cab2
--- /dev/null
+++ b/src/en/space-station-14/areas/core/accessibility/guidelines.md
@@ -0,0 +1,5 @@
+# PR Guildlines
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/core/admin-tools.md b/src/en/space-station-14/areas/core/admin-tools.md
new file mode 100644
index 000000000..bb9bed46f
--- /dev/null
+++ b/src/en/space-station-14/areas/core/admin-tools.md
@@ -0,0 +1,5 @@
+# Admin Tooling
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/core/admin-tools/guidelines.md b/src/en/space-station-14/areas/core/admin-tools/guidelines.md
new file mode 100644
index 000000000..e78a7cab2
--- /dev/null
+++ b/src/en/space-station-14/areas/core/admin-tools/guidelines.md
@@ -0,0 +1,5 @@
+# PR Guildlines
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/core/art.md b/src/en/space-station-14/areas/core/art.md
new file mode 100644
index 000000000..77a4a28b9
--- /dev/null
+++ b/src/en/space-station-14/areas/core/art.md
@@ -0,0 +1,5 @@
+# Art
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/displacement-maps.md b/src/en/space-station-14/areas/core/art/displacement-maps.md
similarity index 100%
rename from src/en/space-station-14/displacement-maps.md
rename to src/en/space-station-14/areas/core/art/displacement-maps.md
diff --git a/src/en/space-station-14/areas/core/art/guidelines.md b/src/en/space-station-14/areas/core/art/guidelines.md
new file mode 100644
index 000000000..e78a7cab2
--- /dev/null
+++ b/src/en/space-station-14/areas/core/art/guidelines.md
@@ -0,0 +1,5 @@
+# PR Guildlines
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/core/character-species/guidelines.md b/src/en/space-station-14/areas/core/character-species/guidelines.md
new file mode 100644
index 000000000..e78a7cab2
--- /dev/null
+++ b/src/en/space-station-14/areas/core/character-species/guidelines.md
@@ -0,0 +1,5 @@
+# PR Guildlines
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/core/characters-species.md b/src/en/space-station-14/areas/core/characters-species.md
new file mode 100644
index 000000000..2e851b96e
--- /dev/null
+++ b/src/en/space-station-14/areas/core/characters-species.md
@@ -0,0 +1,5 @@
+# Character/Species
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/core/combat.md b/src/en/space-station-14/areas/core/combat.md
new file mode 100644
index 000000000..96fd96290
--- /dev/null
+++ b/src/en/space-station-14/areas/core/combat.md
@@ -0,0 +1,5 @@
+# Combat
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/destructible.md b/src/en/space-station-14/areas/core/combat/destructible.md
similarity index 100%
rename from src/en/space-station-14/destructible.md
rename to src/en/space-station-14/areas/core/combat/destructible.md
diff --git a/src/en/space-station-14/areas/core/combat/guidelines.md b/src/en/space-station-14/areas/core/combat/guidelines.md
new file mode 100644
index 000000000..e78a7cab2
--- /dev/null
+++ b/src/en/space-station-14/areas/core/combat/guidelines.md
@@ -0,0 +1,5 @@
+# PR Guildlines
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/core/mapping.md b/src/en/space-station-14/areas/core/mapping.md
new file mode 100644
index 000000000..74fb51355
--- /dev/null
+++ b/src/en/space-station-14/areas/core/mapping.md
@@ -0,0 +1,5 @@
+# Mapping
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/dungeons.md b/src/en/space-station-14/areas/core/mapping/dungeons.md
similarity index 97%
rename from src/en/space-station-14/dungeons.md
rename to src/en/space-station-14/areas/core/mapping/dungeons.md
index 3278c226b..ae33efed7 100644
--- a/src/en/space-station-14/dungeons.md
+++ b/src/en/space-station-14/areas/core/mapping/dungeons.md
@@ -52,7 +52,7 @@ Making new rooms requires a saved map file and prototypes created specifying the
There is a template that can be used below. **Note that there is no limit to size or rooms.**
-[dungeon_template.yml](../assets/misc/dungeon_template.yml)
+[dungeon_template.yml](../../../../assets/misc/dungeon_template.yml)
## Mapping suggestions
diff --git a/src/en/space-station-14/mapping/mapping-checklist.md b/src/en/space-station-14/areas/core/mapping/guidelines.md
similarity index 91%
rename from src/en/space-station-14/mapping/mapping-checklist.md
rename to src/en/space-station-14/areas/core/mapping/guidelines.md
index b36b5b140..d077808fa 100644
--- a/src/en/space-station-14/mapping/mapping-checklist.md
+++ b/src/en/space-station-14/areas/core/mapping/guidelines.md
@@ -1,13 +1,42 @@
-# Mapping Checklist
-
-{{#template ../../templates/outdated.md}}
+# PR Guildlines
```admonish warning
This is an old page, and hasn't been updated in over a year. It does not reflect the current state of the game and should be updated as soon as possible.
+The page will be updated by the mapping work group soon (tm).
Until then, consult other mappers, people with the "Head Mapper" role, and the #cartography discord channel as for what content should be present in your map. **This should not be your sole source of information.**
```
+
+# Mapping sins
+=======
+Don't do any of these. They make for bad looking/feeling maps.
+
+## Ultra-wide hallways
+So the thing about hallways is that they're empty.
+![oversized-hallway.png](../../../../assets/images/mapping/oversized-hallway.png)
+This looks and feels bad to play in, with a very large amount of blank space visually.
+
+### Ways to fix
+
+#### Convert to a parkway
+Filling the visual emptiness with plantlife or other decoratives helps significantly. This shouldn't be overdone, though, and it's preferrable to simply use smaller hallways.
+![parkway-example.png](../../../../assets/images/mapping/parkway-example.png)
+
+## Abdundance of silver/gold tiles
+To put it simply they look terrible, especially combined with decals, and should be used only in extremely specific situations.
+![silver-tiles-hell.png](../../../../assets/images/mapping/silver-tiles-hell.png)
+
+### Ways to fix
+
+#### Just change the theme
+If you're using them to line a "rich feeling" room, say, the HoP's office, opt for instead focusing on a home-y feeling, with woods/etc. Most of the station simply does not have this feel and it'll make them seem exceptional.
+![silver-tiles-hell-except-good.png](../../../../assets/images/mapping/silver-tiles-hell-except-good.png)
+
+
+# Mapping Checklist
+===========
+
This checklist is a general guide on what items are required for typical SS14 station maps. Small maps and non-standard maps may not be able to fit all the content specified, so use this as general guidelines only.
When necessary, the entity ID will be in brackets if it differs greatly from the name of the item. In most cases, you can just search the name. Names with suffixes such as `[filled]` indicate a variant of an entity.
diff --git a/src/en/space-station-14/mapping.md b/src/en/space-station-14/areas/core/mapping/guides/general-guide.md
similarity index 98%
rename from src/en/space-station-14/mapping.md
rename to src/en/space-station-14/areas/core/mapping/guides/general-guide.md
index d947f0439..cdd476457 100644
--- a/src/en/space-station-14/mapping.md
+++ b/src/en/space-station-14/areas/core/mapping/guides/general-guide.md
@@ -33,7 +33,7 @@ To test the map:
# Setup
## With Development Environment
-A [development environment](../general-development/setup/setting-up-a-development-environment.md) and [Git installation](../general-development/setup/git-for-the-ss14-developer.md) are strongly recommended, so that you can keep your local mapping server up to date and submit [pull requests](../general-development/codebase-info/pull-request-guidelines.md).
+A [development environment](../../../../../general-development/setup/setting-up-a-development-environment.md) and [Git installation](../../../../../general-development/setup/git-for-the-ss14-developer.md) are strongly recommended, so that you can keep your local mapping server up to date and submit [pull requests](../../../../../general-development/codebase-info/pull-request-guidelines.md).
### Tools Build
If you are using a development enviroment instead of just hosting a local server, make sure to use Tools instead of Debug/DebugOpt mode. This is because Debug adds artificial lag (making mapping unpleasant) and crashes more (having more assertions enabled).
@@ -46,7 +46,7 @@ dotnet run --project Content.Client --configuration Tools
```
If you are using an IDE, there will be some other way of setting the configuration. For example, in VS there is simply a dropdown menu:
-![mapping-release-dropdown.png](../assets/images/mapping/mapping-release-dropdown.png)
+![mapping-release-dropdown.png](../../../../../assets/images/mapping/mapping-release-dropdown.png)
## Without Development Environment
If you choose not to do this, you will need to download a [recent server build](https://central.spacestation14.io/builds/wizards/builds.html).
@@ -140,7 +140,7 @@ Open the project in Visual Studio Community or your preferred IDE and Build the
# Content
## Map Checklists
-To ensure you have all the required items for each area of your map please refer to the attached checklist [here](../space-station-14/mapping/mapping-checklist.md) as a guide.
+To ensure you have all the required items for each area of your map please refer to the PR review Guidelines [here](../guidelines.md) as a guide.
If your map is now complete, follow the attached checklist [here](https://hackmd.io/@Peptide90/MapPublishChecklist) for a quality control checklist to ensure your map is fully functioning. To run your map for the first time refer to the next section.
diff --git a/src/en/space-station-14/areas/core/player-interaction.md b/src/en/space-station-14/areas/core/player-interaction.md
new file mode 100644
index 000000000..d39dd87b3
--- /dev/null
+++ b/src/en/space-station-14/areas/core/player-interaction.md
@@ -0,0 +1,8 @@
+# Player Interactions
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
+
+## Systems/Mechanics related to common player interactions that are not department specific
+Examples of this would be underlying systems such as: Verbs, Doafters, PDAs, etc.
\ No newline at end of file
diff --git a/src/en/space-station-14/cartridge-loaders.md b/src/en/space-station-14/areas/core/player-interaction/cartridge-loaders.md
similarity index 100%
rename from src/en/space-station-14/cartridge-loaders.md
rename to src/en/space-station-14/areas/core/player-interaction/cartridge-loaders.md
diff --git a/src/en/space-station-14/areas/core/player-interaction/guidelines.md b/src/en/space-station-14/areas/core/player-interaction/guidelines.md
new file mode 100644
index 000000000..e78a7cab2
--- /dev/null
+++ b/src/en/space-station-14/areas/core/player-interaction/guidelines.md
@@ -0,0 +1,5 @@
+# PR Guildlines
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/core/roleplay-lore.md b/src/en/space-station-14/areas/core/roleplay-lore.md
new file mode 100644
index 000000000..3235be631
--- /dev/null
+++ b/src/en/space-station-14/areas/core/roleplay-lore.md
@@ -0,0 +1,5 @@
+# Roleplay/Lore
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/core/roleplay-lore/guidelines.md b/src/en/space-station-14/areas/core/roleplay-lore/guidelines.md
new file mode 100644
index 000000000..e78a7cab2
--- /dev/null
+++ b/src/en/space-station-14/areas/core/roleplay-lore/guidelines.md
@@ -0,0 +1,5 @@
+# PR Guildlines
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/core/round-flow.md b/src/en/space-station-14/areas/core/round-flow.md
new file mode 100644
index 000000000..1844af814
--- /dev/null
+++ b/src/en/space-station-14/areas/core/round-flow.md
@@ -0,0 +1,5 @@
+# Round Flow
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/core-design/antagonists.md b/src/en/space-station-14/areas/core/round-flow/antagonists.md
similarity index 100%
rename from src/en/space-station-14/core-design/antagonists.md
rename to src/en/space-station-14/areas/core/round-flow/antagonists.md
diff --git a/src/en/space-station-14/areas/core/round-flow/guidelines.md b/src/en/space-station-14/areas/core/round-flow/guidelines.md
new file mode 100644
index 000000000..e78a7cab2
--- /dev/null
+++ b/src/en/space-station-14/areas/core/round-flow/guidelines.md
@@ -0,0 +1,5 @@
+# PR Guildlines
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/npcs.md b/src/en/space-station-14/areas/core/round-flow/npcs.md
similarity index 100%
rename from src/en/space-station-14/npcs.md
rename to src/en/space-station-14/areas/core/round-flow/npcs.md
diff --git a/src/en/space-station-14/areas/core/user-interface.md b/src/en/space-station-14/areas/core/user-interface.md
new file mode 100644
index 000000000..a573a6b3e
--- /dev/null
+++ b/src/en/space-station-14/areas/core/user-interface.md
@@ -0,0 +1,5 @@
+# User Interface
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/core/user-interface/guidelines.md b/src/en/space-station-14/areas/core/user-interface/guidelines.md
new file mode 100644
index 000000000..e78a7cab2
--- /dev/null
+++ b/src/en/space-station-14/areas/core/user-interface/guidelines.md
@@ -0,0 +1,5 @@
+# PR Guildlines
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments.md b/src/en/space-station-14/areas/departments.md
new file mode 100644
index 000000000..f0b07a653
--- /dev/null
+++ b/src/en/space-station-14/areas/departments.md
@@ -0,0 +1,6 @@
+# Departments
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
+a department is a series of tubes
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments/atmos.md b/src/en/space-station-14/areas/departments/atmos.md
new file mode 100644
index 000000000..78fa0f7e1
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/atmos.md
@@ -0,0 +1,5 @@
+# Atmos
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments/atmos/guidelines.md b/src/en/space-station-14/areas/departments/atmos/guidelines.md
new file mode 100644
index 000000000..e78a7cab2
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/atmos/guidelines.md
@@ -0,0 +1,5 @@
+# PR Guildlines
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments/cargo-salvage.md b/src/en/space-station-14/areas/departments/cargo-salvage.md
new file mode 100644
index 000000000..9e63e7b9e
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/cargo-salvage.md
@@ -0,0 +1,5 @@
+# Cargo/Salvage
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments/cargo-salvage/guidelines.md b/src/en/space-station-14/areas/departments/cargo-salvage/guidelines.md
new file mode 100644
index 000000000..e78a7cab2
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/cargo-salvage/guidelines.md
@@ -0,0 +1,5 @@
+# PR Guildlines
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments/command.md b/src/en/space-station-14/areas/departments/command.md
new file mode 100644
index 000000000..1a9998fe5
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/command.md
@@ -0,0 +1,5 @@
+# Command
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments/command/guidelines.md b/src/en/space-station-14/areas/departments/command/guidelines.md
new file mode 100644
index 000000000..e78a7cab2
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/command/guidelines.md
@@ -0,0 +1,5 @@
+# PR Guildlines
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments/engineering.md b/src/en/space-station-14/areas/departments/engineering.md
new file mode 100644
index 000000000..6f46533a6
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/engineering.md
@@ -0,0 +1,5 @@
+# Engineering
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/construction.md b/src/en/space-station-14/areas/departments/engineering/construction.md
similarity index 100%
rename from src/en/space-station-14/construction.md
rename to src/en/space-station-14/areas/departments/engineering/construction.md
diff --git a/src/en/space-station-14/device-network.md b/src/en/space-station-14/areas/departments/engineering/device-network.md
similarity index 100%
rename from src/en/space-station-14/device-network.md
rename to src/en/space-station-14/areas/departments/engineering/device-network.md
diff --git a/src/en/space-station-14/areas/departments/engineering/guidelines.md b/src/en/space-station-14/areas/departments/engineering/guidelines.md
new file mode 100644
index 000000000..e78a7cab2
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/engineering/guidelines.md
@@ -0,0 +1,5 @@
+# PR Guildlines
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/node-networks.md b/src/en/space-station-14/areas/departments/engineering/node-networks.md
similarity index 100%
rename from src/en/space-station-14/node-networks.md
rename to src/en/space-station-14/areas/departments/engineering/node-networks.md
diff --git a/src/en/space-station-14/pow3r.md b/src/en/space-station-14/areas/departments/engineering/pow3r.md
similarity index 100%
rename from src/en/space-station-14/pow3r.md
rename to src/en/space-station-14/areas/departments/engineering/pow3r.md
diff --git a/src/en/space-station-14/areas/departments/medical.md b/src/en/space-station-14/areas/departments/medical.md
new file mode 100644
index 000000000..8cb78ad19
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/medical.md
@@ -0,0 +1,5 @@
+# Medical
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments/medical/guidelines.md b/src/en/space-station-14/areas/departments/medical/guidelines.md
new file mode 100644
index 000000000..e78a7cab2
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/medical/guidelines.md
@@ -0,0 +1,5 @@
+# PR Guildlines
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments/science.md b/src/en/space-station-14/areas/departments/science.md
new file mode 100644
index 000000000..22a6cad81
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/science.md
@@ -0,0 +1,5 @@
+# Science
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/chemistry.md b/src/en/space-station-14/areas/departments/science/chemistry.md
similarity index 100%
rename from src/en/space-station-14/chemistry.md
rename to src/en/space-station-14/areas/departments/science/chemistry.md
diff --git a/src/en/space-station-14/chemistry/metabolism.md b/src/en/space-station-14/areas/departments/science/chemistry/metabolism.md
similarity index 100%
rename from src/en/space-station-14/chemistry/metabolism.md
rename to src/en/space-station-14/areas/departments/science/chemistry/metabolism.md
diff --git a/src/en/space-station-14/chemistry/reactions.md b/src/en/space-station-14/areas/departments/science/chemistry/reactions.md
similarity index 100%
rename from src/en/space-station-14/chemistry/reactions.md
rename to src/en/space-station-14/areas/departments/science/chemistry/reactions.md
diff --git a/src/en/space-station-14/chemistry/reagents.md b/src/en/space-station-14/areas/departments/science/chemistry/reagents.md
similarity index 100%
rename from src/en/space-station-14/chemistry/reagents.md
rename to src/en/space-station-14/areas/departments/science/chemistry/reagents.md
diff --git a/src/en/space-station-14/chemistry/solution-containers.md b/src/en/space-station-14/areas/departments/science/chemistry/solution-containers.md
similarity index 100%
rename from src/en/space-station-14/chemistry/solution-containers.md
rename to src/en/space-station-14/areas/departments/science/chemistry/solution-containers.md
diff --git a/src/en/space-station-14/areas/departments/science/guidelines.md b/src/en/space-station-14/areas/departments/science/guidelines.md
new file mode 100644
index 000000000..e78a7cab2
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/science/guidelines.md
@@ -0,0 +1,5 @@
+# PR Guildlines
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments/security.md b/src/en/space-station-14/areas/departments/security.md
new file mode 100644
index 000000000..7a31b9a9e
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/security.md
@@ -0,0 +1,5 @@
+# Security
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments/security/guidelines.md b/src/en/space-station-14/areas/departments/security/guidelines.md
new file mode 100644
index 000000000..e78a7cab2
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/security/guidelines.md
@@ -0,0 +1,5 @@
+# PR Guildlines
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments/service.md b/src/en/space-station-14/areas/departments/service.md
new file mode 100644
index 000000000..7baad5027
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/service.md
@@ -0,0 +1,5 @@
+# Service
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments/service/guidelines.md b/src/en/space-station-14/areas/departments/service/guidelines.md
new file mode 100644
index 000000000..e78a7cab2
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/service/guidelines.md
@@ -0,0 +1,5 @@
+# PR Guildlines
+
+```admonish warning "Attention: Placeholder!"
+This section is a placeholder, pending a design-doc being created by the related work-group
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/core-design/principles.md b/src/en/space-station-14/design-principles.md
similarity index 100%
rename from src/en/space-station-14/core-design/principles.md
rename to src/en/space-station-14/design-principles.md
diff --git a/src/en/space-station-14/core-design.md b/src/en/space-station-14/design.md
similarity index 94%
rename from src/en/space-station-14/core-design.md
rename to src/en/space-station-14/design.md
index 9338144b8..fa1cc6b61 100644
--- a/src/en/space-station-14/core-design.md
+++ b/src/en/space-station-14/design.md
@@ -19,7 +19,7 @@ Questions around Core Game Design should be directed towards the Design Group on
# Core Pillars
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.
-The pillars serve as guideposts for creating a cohesive design for SS14. Further detail about each can be found in: [Design Principles](core-design/principles.md).
+The pillars serve as guideposts for creating a cohesive design for SS14. Further detail about each can be found in: [Design Principles](design-principles.md).
## Chaotic
- 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.
@@ -30,8 +30,4 @@ The pillars serve as guideposts for creating a cohesive design for SS14. Further
## Intuitive and Inter-Connected Simulation
- 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.
## Player Interaction/Agency
-- 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.
-
- ## Categories:
- - [Design Principles](core-design/principles.md)
- - [Antagonists](core-design/antagonists.md)
+- 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.
\ No newline at end of file
diff --git a/src/en/space-station-14/mapping/mapping-sins.md b/src/en/space-station-14/mapping/mapping-sins.md
deleted file mode 100644
index 4ad7fb9d7..000000000
--- a/src/en/space-station-14/mapping/mapping-sins.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Mapping sins
-Don't do any of these. They make for bad looking/feeling maps.
-
-## Ultra-wide hallways
-So the thing about hallways is that they're empty.
-![oversized-hallway.png](../../assets/images/mapping/oversized-hallway.png)
-This looks and feels bad to play in, with a very large amount of blank space visually.
-
-### Ways to fix
-
-#### Convert to a parkway
-Filling the visual emptiness with plantlife or other decoratives helps significantly. This shouldn't be overdone, though, and it's preferrable to simply use smaller hallways.
-![parkway-example.png](../../assets/images/mapping/parkway-example.png)
-
-## Abdundance of silver/gold tiles
-To put it simply they look terrible, especially combined with decals, and should be used only in extremely specific situations.
-![silver-tiles-hell.png](../../assets/images/mapping/silver-tiles-hell.png)
-
-### Ways to fix
-
-#### Just change the theme
-If you're using them to line a "rich feeling" room, say, the HoP's office, opt for instead focusing on a home-y feeling, with woods/etc. Most of the station simply does not have this feel and it'll make them seem exceptional.
-![silver-tiles-hell-except-good.png](../../assets/images/mapping/silver-tiles-hell-except-good.png)
\ No newline at end of file
diff --git a/src/en/ss14-by-example/introduction-to-ss14-by-example.md b/src/en/ss14-by-example/introduction-to-ss14-by-example.md
index 858dfef5c..4f94ec212 100644
--- a/src/en/ss14-by-example/introduction-to-ss14-by-example.md
+++ b/src/en/ss14-by-example/introduction-to-ss14-by-example.md
@@ -6,6 +6,6 @@ SS14 By Example is a knowledgebase for figuring out how to do a lot of simple ta
If you're coming here from BYOND or SS13, hello! These docs are written with that audience in mind, and it tries to translate some broad topics from SS13 into SS14 and Robust Toolbox.
-SS14 By Example will not cover extending content that already exists in SS14, such as [construction](../space-station-14/construction.md), [chemistry](../space-station-14/chemistry.md), body system, or botany. These should either be evident from the code, or are covered in **Content Documentation**. You can see the topics that will be covered in the sidebar, or at the bottom of this page.
+SS14 By Example will not cover extending content that already exists in SS14, such as [construction](../space-station-14/areas/departments/engineering/construction.md), [chemistry](../space-station-14/areas/departments/science/chemistry.md), body system, or botany. These should either be evident from the code, or are covered in **Content Documentation**. You can see the topics that will be covered in the sidebar, or at the bottom of this page.
SS14 By Example will also not cover [basic setup](../general-development/setup.md) or cover any [codebase info](../general-development/codebase-info.md) like conventions or common nomenclature, as these have their own documentation elsewhere on this site.
\ No newline at end of file
diff --git a/src/en/templates/legacy.md b/src/en/templates/legacy.md
new file mode 100644
index 000000000..9d480bb3a
--- /dev/null
+++ b/src/en/templates/legacy.md
@@ -0,0 +1,3 @@
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and needs to be updated
+```
\ No newline at end of file
diff --git a/src/index.md b/src/index.md
index 75cf78cff..0d04b48b8 100644
--- a/src/index.md
+++ b/src/index.md
@@ -21,8 +21,8 @@ If you would like to make contributions to this documentation site, it's hosted
- [:question: How do I code?](en/general-development/setup/howdoicode.md)
- [:package: Setting up the Dev Environment](en/general-development/setup/setting-up-a-development-environment.md)
-- [:page_with_curl: Core Game Design](en/space-station-14/core-design.md)
-- [:world_map: Mapping](en/space-station-14/mapping.md)
+- [:page_with_curl: Core Game Design](en/space-station-14/design.md)
+- [:world_map: Mapping](en/space-station-14/areas/core/mapping.md)
- [:chart_with_upwards_trend: Git for the SS14 Developer](en/general-development/setup/git-for-the-ss14-developer.md)
From 43c552658e3cec66b635eeb399689ce17e2e686f Mon Sep 17 00:00:00 2001
From: Jezithyr
Date: Sat, 20 Apr 2024 20:27:15 -0700
Subject: [PATCH 21/80] Fix - moved chem to med from science (#202)
---
src/SUMMARY.md | 10 +++++-----
.../departments/{science => medical}/chemistry.md | 0
.../{science => medical}/chemistry/metabolism.md | 0
.../{science => medical}/chemistry/reactions.md | 0
.../{science => medical}/chemistry/reagents.md | 0
.../chemistry/solution-containers.md | 0
.../ss14-by-example/introduction-to-ss14-by-example.md | 2 +-
7 files changed, 6 insertions(+), 6 deletions(-)
rename src/en/space-station-14/areas/departments/{science => medical}/chemistry.md (100%)
rename src/en/space-station-14/areas/departments/{science => medical}/chemistry/metabolism.md (100%)
rename src/en/space-station-14/areas/departments/{science => medical}/chemistry/reactions.md (100%)
rename src/en/space-station-14/areas/departments/{science => medical}/chemistry/reagents.md (100%)
rename src/en/space-station-14/areas/departments/{science => medical}/chemistry/solution-containers.md (100%)
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index dc2c7be58..bfbe6e6eb 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -147,13 +147,13 @@ Space Station 14
- [Pow3r](en/space-station-14/areas/departments/engineering/pow3r.md)
- [Medical](en/space-station-14/areas/departments/medical.md)
- [PR Guidelines](en/space-station-14/areas/departments/medical/guidelines.md)
+ - [Chemistry](en/space-station-14/areas/departments/medical/chemistry.md)
+ - [Metabolism](en/space-station-14/areas/departments/medical/chemistry/metabolism.md)
+ - [Reactions](en/space-station-14/areas/departments/medical/chemistry/reactions.md)
+ - [Reagents](en/space-station-14/areas/departments/medical/chemistry/reagents.md)
+ - [Solution Containers](en/space-station-14/areas/departments/medical/chemistry/solution-containers.md)
- [Science](en/space-station-14/areas/departments/science.md)
- [PR Guidelines](en/space-station-14/areas/departments/science/guidelines.md)
- - [Chemistry](en/space-station-14/areas/departments/science/chemistry.md)
- - [Metabolism](en/space-station-14/areas/departments/science/chemistry/metabolism.md)
- - [Reactions](en/space-station-14/areas/departments/science/chemistry/reactions.md)
- - [Reagents](en/space-station-14/areas/departments/science/chemistry/reagents.md)
- - [Solution Containers](en/space-station-14/areas/departments/science/chemistry/solution-containers.md)
- [Security](en/space-station-14/areas/departments/security.md)
- [PR Guidelines](en/space-station-14/areas/departments/security/guidelines.md)
- [Service](en/space-station-14/areas/departments/service.md)
diff --git a/src/en/space-station-14/areas/departments/science/chemistry.md b/src/en/space-station-14/areas/departments/medical/chemistry.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/science/chemistry.md
rename to src/en/space-station-14/areas/departments/medical/chemistry.md
diff --git a/src/en/space-station-14/areas/departments/science/chemistry/metabolism.md b/src/en/space-station-14/areas/departments/medical/chemistry/metabolism.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/science/chemistry/metabolism.md
rename to src/en/space-station-14/areas/departments/medical/chemistry/metabolism.md
diff --git a/src/en/space-station-14/areas/departments/science/chemistry/reactions.md b/src/en/space-station-14/areas/departments/medical/chemistry/reactions.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/science/chemistry/reactions.md
rename to src/en/space-station-14/areas/departments/medical/chemistry/reactions.md
diff --git a/src/en/space-station-14/areas/departments/science/chemistry/reagents.md b/src/en/space-station-14/areas/departments/medical/chemistry/reagents.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/science/chemistry/reagents.md
rename to src/en/space-station-14/areas/departments/medical/chemistry/reagents.md
diff --git a/src/en/space-station-14/areas/departments/science/chemistry/solution-containers.md b/src/en/space-station-14/areas/departments/medical/chemistry/solution-containers.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/science/chemistry/solution-containers.md
rename to src/en/space-station-14/areas/departments/medical/chemistry/solution-containers.md
diff --git a/src/en/ss14-by-example/introduction-to-ss14-by-example.md b/src/en/ss14-by-example/introduction-to-ss14-by-example.md
index 4f94ec212..d0af76b44 100644
--- a/src/en/ss14-by-example/introduction-to-ss14-by-example.md
+++ b/src/en/ss14-by-example/introduction-to-ss14-by-example.md
@@ -6,6 +6,6 @@ SS14 By Example is a knowledgebase for figuring out how to do a lot of simple ta
If you're coming here from BYOND or SS13, hello! These docs are written with that audience in mind, and it tries to translate some broad topics from SS13 into SS14 and Robust Toolbox.
-SS14 By Example will not cover extending content that already exists in SS14, such as [construction](../space-station-14/areas/departments/engineering/construction.md), [chemistry](../space-station-14/areas/departments/science/chemistry.md), body system, or botany. These should either be evident from the code, or are covered in **Content Documentation**. You can see the topics that will be covered in the sidebar, or at the bottom of this page.
+SS14 By Example will not cover extending content that already exists in SS14, such as [construction](../space-station-14/areas/departments/engineering/construction.md), [chemistry](../space-station-14/areas/departments/medical/chemistry.md), body system, or botany. These should either be evident from the code, or are covered in **Content Documentation**. You can see the topics that will be covered in the sidebar, or at the bottom of this page.
SS14 By Example will also not cover [basic setup](../general-development/setup.md) or cover any [codebase info](../general-development/codebase-info.md) like conventions or common nomenclature, as these have their own documentation elsewhere on this site.
\ No newline at end of file
From d3384c2de97b168d855156d34bf08d8e3521eb03 Mon Sep 17 00:00:00 2001
From: Jezithyr
Date: Sat, 20 Apr 2024 21:31:48 -0700
Subject: [PATCH 22/80] Moved design proposals to folders in game areas (#203)
---
src/SUMMARY.md | 93 ++++++--
src/en/general-proposals/robusthub.md | 110 +++++++++
.../core/accessibility/proposals/.gitkeep | 0
.../areas/core/admin-tools/proposals/.gitkeep | 0
.../areas/core/art/proposals/.gitkeep | 0
.../core/character-species/proposals/.gitkeep | 0
.../areas/core/combat/proposals/.gitkeep | 0
.../areas/core/mapping/proposals/.gitkeep | 0
.../core/player-interaction/grid-inventory.md | 72 ++++++
.../proposals/pda-messaging.md | 115 ++++++++++
.../core/roleplay-lore/proposals/.gitkeep | 0
.../round-flow/antagonists/exterminator.md | 47 ++++
.../core/round-flow/antagonists/thief.md | 103 +++++++++
.../proposals/cleanup-crew-gamemode.md | 56 +++++
.../round-flow/proposals/game-director.md | 215 ++++++++++++++++++
.../proposals/pizza-delivery-critter.md | 87 +++++++
.../core/round-flow/proposals/rogue-drones.md | 71 ++++++
.../core/round-flow/proposals/turf-war.md | 41 ++++
.../user-interface/proposals/statpanels.md | 77 +++++++
.../atmos/proposals/atmos-rework.md | 120 ++++++++++
.../cargo-salvage/proposals/.gitkeep | 0
.../departments/command/proposals/.gitkeep | 0
.../emogarbage-machine-upgrading-rework.md | 1 +
.../proposals/engine-containment.md | 52 +++++
.../proposals/machine-upgrading-rework.md | 95 ++++++++
.../engineering/proposals/power-generation.md | 130 +++++++++++
.../engineering/proposals/signaller-rework.md | 96 ++++++++
.../departments/medical/proposals/.gitkeep | 0
.../departments/science/anomaly-cores.md | 49 ++++
.../science/proposals/xenoarch-redux.md | 176 ++++++++++++++
.../security/proposals/genpop-prisoners.md | 63 +++++
.../service/proposals/plant-genetics.md | 55 +++++
32 files changed, 1901 insertions(+), 23 deletions(-)
create mode 100644 src/en/general-proposals/robusthub.md
create mode 100644 src/en/space-station-14/areas/core/accessibility/proposals/.gitkeep
create mode 100644 src/en/space-station-14/areas/core/admin-tools/proposals/.gitkeep
create mode 100644 src/en/space-station-14/areas/core/art/proposals/.gitkeep
create mode 100644 src/en/space-station-14/areas/core/character-species/proposals/.gitkeep
create mode 100644 src/en/space-station-14/areas/core/combat/proposals/.gitkeep
create mode 100644 src/en/space-station-14/areas/core/mapping/proposals/.gitkeep
create mode 100644 src/en/space-station-14/areas/core/player-interaction/grid-inventory.md
create mode 100644 src/en/space-station-14/areas/core/player-interaction/proposals/pda-messaging.md
create mode 100644 src/en/space-station-14/areas/core/roleplay-lore/proposals/.gitkeep
create mode 100644 src/en/space-station-14/areas/core/round-flow/antagonists/exterminator.md
create mode 100644 src/en/space-station-14/areas/core/round-flow/antagonists/thief.md
create mode 100644 src/en/space-station-14/areas/core/round-flow/proposals/cleanup-crew-gamemode.md
create mode 100644 src/en/space-station-14/areas/core/round-flow/proposals/game-director.md
create mode 100644 src/en/space-station-14/areas/core/round-flow/proposals/pizza-delivery-critter.md
create mode 100644 src/en/space-station-14/areas/core/round-flow/proposals/rogue-drones.md
create mode 100644 src/en/space-station-14/areas/core/round-flow/proposals/turf-war.md
create mode 100644 src/en/space-station-14/areas/core/user-interface/proposals/statpanels.md
create mode 100644 src/en/space-station-14/areas/departments/atmos/proposals/atmos-rework.md
create mode 100644 src/en/space-station-14/areas/departments/cargo-salvage/proposals/.gitkeep
create mode 100644 src/en/space-station-14/areas/departments/command/proposals/.gitkeep
create mode 100644 src/en/space-station-14/areas/departments/engineering/proposals/emogarbage-machine-upgrading-rework.md
create mode 100644 src/en/space-station-14/areas/departments/engineering/proposals/engine-containment.md
create mode 100644 src/en/space-station-14/areas/departments/engineering/proposals/machine-upgrading-rework.md
create mode 100644 src/en/space-station-14/areas/departments/engineering/proposals/power-generation.md
create mode 100644 src/en/space-station-14/areas/departments/engineering/proposals/signaller-rework.md
create mode 100644 src/en/space-station-14/areas/departments/medical/proposals/.gitkeep
create mode 100644 src/en/space-station-14/areas/departments/science/anomaly-cores.md
create mode 100644 src/en/space-station-14/areas/departments/science/proposals/xenoarch-redux.md
create mode 100644 src/en/space-station-14/areas/departments/security/proposals/genpop-prisoners.md
create mode 100644 src/en/space-station-14/areas/departments/service/proposals/plant-genetics.md
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index bfbe6e6eb..a4220a8ab 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -11,6 +11,8 @@ Meta
- [Docs Example Page](en/meta/docs-example-page.md)
- [Docs are for Discoverability](en/meta/docs-are-for-discoverability.md)
+- [Feature Proposal Template](en/templates/proposal.md)
+
General Development
===================
@@ -105,46 +107,98 @@ Space Station 14
- [Global]()
- [Accessibility](en/space-station-14/areas/core/accessibility.md)
- [PR Guidelines](en/space-station-14/areas/core/accessibility/guidelines.md)
+
+ - [Proposals]()
+
- [Admin Tooling](en/space-station-14/areas/core/admin-tools.md)
- [PR Guidelines](en/space-station-14/areas/core/admin-tools/guidelines.md)
+
+ - [Proposals]()
+
- [Art](en/space-station-14/areas/core/art.md)
- [PR Guidelines](en/space-station-14/areas/core/art/guidelines.md)
- [Displacement Maps](en/space-station-14/areas/core/art/displacement-maps.md)
+
+ - [Proposals]()
+
- [Character/Species](en/space-station-14/areas/core/characters-species.md)
- [PR Guidelines](en/space-station-14/areas/core/character-species/guidelines.md)
+
+ - [Proposals]()
+
- [Combat](en/space-station-14/areas/core/combat.md)
- [PR Guidelines](en/space-station-14/areas/core/combat/guidelines.md)
- [Destructible](en/space-station-14/areas/core/combat/destructible.md)
+
+ - [Proposals]()
+
- [Mapping](en/space-station-14/areas/core/mapping.md)
- [PR Guidelines](en/space-station-14/areas/core/mapping/guidelines.md)
- [Dungeons](en/space-station-14/areas/core/mapping/dungeons.md)
- [Guides]()
- [General Guide](en/space-station-14/areas/core/mapping/guides/general-guide.md)
+ - [Proposals]()
+
- [Player Interaction](en/space-station-14/areas/core/player-interaction.md)
- [PR Guidelines](en/space-station-14/areas/core/player-interaction/guidelines.md)
+ - [PDA Messaging](en/space-station-14/areas/core/player-interaction/proposals/pda-messaging.md)
+ - [Grid Inventory](en/space-station-14/areas/core/player-interaction/grid-inventory.md)
+
+ - [Proposals]()
+
- [Roleplay/Lore](en/space-station-14/areas/core/roleplay-lore.md)
- [PR Guidelines](en/space-station-14/areas/core/roleplay-lore/guidelines.md)
+
+ - [Proposals]()
+
- [Roundflow](en/space-station-14/areas/core/round-flow.md)
- [PR Guidelines](en/space-station-14/areas/core/round-flow/guidelines.md)
- [Antagonists](en/space-station-14/areas/core/round-flow/antagonists.md)
+ - [Exterimator](en/space-station-14/areas/core/round-flow/antagonists/exterminator.md)
+ - [Thief](en/space-station-14/areas/core/round-flow/antagonists/thief.md)
+
+ - [Proposals]()
+ - [Cleanup Crew Gamemode](en/space-station-14/areas/core/round-flow/proposals/cleanup-crew-gamemode.md)
+ - [Game Director](en/space-station-14/areas/core/round-flow/proposals/game-director.md)
+ - [Pizza Delivery Critter](en/space-station-14/areas/core/round-flow/proposals/pizza-delivery-critter.md)
+ - [Rogue Drones](en/space-station-14/areas/core/round-flow/proposals/rogue-drones.md)
+ - [Turf War](en/space-station-14/areas/core/round-flow/proposals/turf-war.md)
+
- [User Interface](en/space-station-14/areas/core/user-interface.md)
- [PR Guidelines](en/space-station-14/areas/core/user-interface/guidelines.md)
-
+
+ - [Proposals]()
+ - [Stat Panels](en/space-station-14/areas/core/user-interface/proposals/statpanels.md)
- [Departments](en/space-station-14/areas/departments.md)
- [Atmos](en/space-station-14/areas/departments/atmos.md)
- [PR Guidelines](en/space-station-14/areas/departments/atmos/guidelines.md)
+ - [Proposals]()
+ - [Atmos Rework](en/space-station-14/areas/departments/atmos/proposals/atmos-rework.md)
+
- [Cargo/Salvage](en/space-station-14/areas/departments/cargo-salvage.md)
- [PR Guidelines](en/space-station-14/areas/departments/cargo-salvage/guidelines.md)
+ - [Proposals]()
+
- [Command](en/space-station-14/areas/departments/command.md)
- [PR Guidelines](en/space-station-14/areas/departments/command/guidelines.md)
+ - [Proposals]()
+
- [Engineering](en/space-station-14/areas/departments/engineering.md)
- [PR Guidelines](en/space-station-14/areas/departments/engineering/guidelines.md)
+ - [Machine Upgrading Rework](en/space-station-14/areas/departments/engineering/proposals/emogarbage-machine-upgrading-rework.md)
- [Construction](en/space-station-14/areas/departments/engineering/construction.md)\
- [Node Networks](en/space-station-14/areas/departments/engineering/node-networks.md)
- [Device Network](en/space-station-14/areas/departments/engineering/device-network.md)
- [Pow3r](en/space-station-14/areas/departments/engineering/pow3r.md)
+
+ - [Proposals]()
+ - [Engine Containment](en/space-station-14/areas/departments/engineering/proposals/engine-containment.md)
+ - [Machine Upgrading Rework](en/space-station-14/areas/departments/engineering/proposals/machine-upgrading-rework.md)
+ - [Power Generation Rework](en/space-station-14/areas/departments/engineering/proposals/power-generation.md)
+ - [Signaller Rework](en/space-station-14/areas/departments/engineering/proposals/signaller-rework.md)
+
- [Medical](en/space-station-14/areas/departments/medical.md)
- [PR Guidelines](en/space-station-14/areas/departments/medical/guidelines.md)
- [Chemistry](en/space-station-14/areas/departments/medical/chemistry.md)
@@ -152,39 +206,32 @@ Space Station 14
- [Reactions](en/space-station-14/areas/departments/medical/chemistry/reactions.md)
- [Reagents](en/space-station-14/areas/departments/medical/chemistry/reagents.md)
- [Solution Containers](en/space-station-14/areas/departments/medical/chemistry/solution-containers.md)
+
+ - [Proposals]()
+
- [Science](en/space-station-14/areas/departments/science.md)
- [PR Guidelines](en/space-station-14/areas/departments/science/guidelines.md)
+ - [Anomaly Cores](en/space-station-14/areas/departments/science/anomaly-cores.md)
+
+ - [Proposals]()
+
- [Security](en/space-station-14/areas/departments/security.md)
- [PR Guidelines](en/space-station-14/areas/departments/security/guidelines.md)
+
+ - [Proposals]()
+ - [GenPop Prisoners](en/space-station-14/areas/departments/security/proposals/genpop-prisoners.md)
- [Service](en/space-station-14/areas/departments/service.md)
- [PR Guidelines](en/space-station-14/areas/departments/service/guidelines.md)
-Design Proposals
-================
-
-----------------------
+ - [Proposals]()
+ - [Plant Genetics](en/space-station-14/areas/departments/service/proposals/plant-genetics.md)
-- [Feature Proposal Template](en/templates/proposal.md)
+General Proposals
+================
----------------------
-- [Anomaly Cores](en/proposals/mirrorcult-anomaly-cores.md)
-- [Machine Upgrading Rework](en/proposals/emogarbage-machine-upgrading-rework.md)
-- [PDA Messaging](en/proposals/julian-vasilis-pda-messaging.md)
-- [Plant Genetics](en/proposals/deltanedas-plant-genetics.md)
-- [Security Genpop Rework](en/proposals/ike709-genpop-security.md)
-- [Rogue Drones](en/proposals/mirrorcult-rogue-drones.md)
-- [Game Director](en/proposals/tomleys-game-director.md)
-- [XenoArch Redux (3moArch)](en/proposals/emogarbage-xenoarch-redux.md)
-- [Grid Inventory](en/proposals/emogarbage-grid-inventory.md)
-- [Atmos Roadmap](en/proposals/notafet-atmos.md)
-- [Cleanup Crew](en/proposals/mirrorcult-cleanup-crew-gamemode.md)
-- [Exterminator](en/proposals/deltanedas-exterminator.md)
-- [Power Generation Pattern](en/proposals/tday93-power-generation.md)
-- [Turf War](en/proposals/deltanedas-turf-war.md)
-- [Signaller Rework](en/proposals/deltanedas-signaller-rework.md)
-- [Thief antagonist](en/proposals/theshued-thief.md)
-- [Pizza Delivery Critter](en/proposals/fairlysadpanda-pizzadelivery.md)
+- [Robust Hub](en/general-proposals/robusthub.md)
Server Hosting
==============
diff --git a/src/en/general-proposals/robusthub.md b/src/en/general-proposals/robusthub.md
new file mode 100644
index 000000000..cc585c027
--- /dev/null
+++ b/src/en/general-proposals/robusthub.md
@@ -0,0 +1,110 @@
+# RobustHub™
+
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| ike709 | :x: No | WYCI |
+
+## Overview
+
+Redesigning the launcher UI/UX and server hub concept to better facilitate creating and playing games developed in Robust Toolbox that *aren't* Space Station 14.
+
+#### This proposal is a high-level conceptual overview. Please do not bikeshed specific details such as every potential field for RobustHub metadata. Once this is conceptually approved, the bikeshedding can commence in subsequent design documents fleshing out each aspect of the design.
+
+Even the nomenclature used (e.g. "Game Hub") is subject to change but preferably won't be bikeshedded prior to overall proposal approval.
+
+## Games & Game Hubs
+
+### Defining "Game"
+In this context a "game" is referring to a single *project* such as Space Station 14, OpenDream, or RobustSand. Forks of SS14 are considered separate codebases, but still part of the SS14 "game".
+
+### Server Hubs
+The current concept of a hub is essentially just a list of servers. Under this new system these would effectively be the same, except now each server hub will be associated with one or more "games". These will be referred to explicitly as "Server Hubs" to distinguish them from "Game Hubs".
+
+Each Server Hub will have a whitelist of game(s) that can be advertised on it. For example, the official WizDen Server Hub could support both SS14 and RobustPong servers. When a server attempts to advertise on a Server Hub, it must declare the game that it is running and it must be one of the Server Hub's whitelisted games to advertise successfully. Server Hub operators are responsible for moderating the servers that are permitted to advertise on their hub, and ensuring that information such as the advertised game is accurate.
+
+When a player adds an additional Server Hub in the launcher, the additional servers will be associated with the correct games using the game identifier being advertised by the server. More on this later in the launcher section. A potential quality-of-life enhancement would be to allow players to toggle individual games on a per-Hub basis (e.g. if I were running my own alternative Server Hub for OpenDream servers dubbed "IkeHub", which advertises both SS13 and Eternia servers, a player may wish to disable polling the hub for Eternia servers if they only play SS13).
+
+### Game Hubs
+A higher-level hub dubbed "Game Hub" will fill a similar role to server hubs, but instead of providing a list of servers they will provide a list of *games* and their associated metadata that the launcher needs in order to play them and/or browse their Server Hub. **Note:** The launcher is only intended to support a singular "Game Hub", and the concept exists to provide examples of how Robust Toolbox can be utilized separately from Space Wizards Federation infrastructure, such as games developed independently of SS14 or communities who wish to "hard fork" their own infrastructure.
+
+The list of games available on a Game Hub is under the purview of the hub's operators. The official Robust Toolbox Game Hub (RobustHub) will be managed by the Space Wizards Federation. The system now looks something like this ([direct link](https://i.imgur.com/lyRfy8t.png)):
+
+
+
+### RobustHub Repository
+A new Space Wizards repo will be created called RobustHub (or similar). This repository will provide the "official" Game Hub that will easily be accessible with any official build of the launcher.
+
+Each game will have a directory in the repository with a variety of metadata and branding files (e.g. the game's default logo). I expect this will be fleshed out and bikeshedded more thoroughly in a separate design document, but metadata would consist of information such as:
+- Game name (obviously)
+- Creator/Developer information
+- Official Discord/GitHub/Website/etc.
+- URL to pull News from (like the existing News tab in the SS14 launcher currently)
+- If the game is singleplayer, multiplayer, or both.
+ - Multiplayer games will include the default/official Server Hub URL for the game
+ - Multiplayer games can decide whether or not to allow adding alternate unofficial hubs in the launcher (obviously SS14 would allow them, but Johnny GameDeveloper might want full control of the servers for his game)
+ - Exclusively-singleplayer games will point to the content bundle download URL
+ - (Side note: the existing SS14 launcher still can't launch singleplayer games you've already downloaded like RobustSand)
+
+Adding a game to RobustHub should be as straightforward as creating a pull request and meeting whatever criteria is deemed sufficient by the RT project managers to be considered a separate game.
+
+The process of who will be permitted to update a game's hub entry and how will be fleshed out in a future design document dedicated to RobustHub pending this proposal's approval.
+
+## Launcher Changes
+
+ I couldn't find a way to articulate these launcher changes that doesn't make it sound a little crazy at first, so I advise reading all of this section before judging it.
+
+### Robust Launcher
+The SS14 launcher as it exists currently will no longer be maintained as a project. Instead the launcher will be stripped of all SS14 branding in favor of Robust Toolbox branding. The "Servers" tab will be nuked in favor of an interface similar to the BYOND pager, except with RobustHub games instead ([direct link](https://i.imgur.com/DSXdzyP.png)):
+
+
+
+I don't expect it to look exactly the same; for example, we may have a separate page for singleplayer games. But players will be able to download, play, or browse the server list for any RobustHub game from Robust Launcher.
+
+#### Adding Alternate Server Hubs
+As previously mentioned, the launcher will support allowing players to add additional Server Hubs. This should be as straightforward as adding a URL to a list in the launcher settings, with the launcher handling it from there. The launcher will check to make sure a game's RobustHub metadata permits alternate hubs before polling an alternate Server Hub for that particular game. When a player goes to a particular game's server list, the launcher will poll the Server Hub only for servers with that game's identifier. On the game's server list, each server entry will include a field displaying the Server Hub it was pulled from, and the list should support optionally filtering by Server Hub.
+
+Adding alternate Server Hubs should warn the player about potential moderation issues compared to using official Server Hubs. We may wish to somehow present each hub's rules to the player when the hub is being added in the launcher.
+
+#### Optional: Steam Release
+I'm of the opinion that Robust Toolbox should have its own dedicated Steam page which ships Robust Launcher directly, to reduce confusion when people want to play other RT projects like OpenDream via Steam. I'm not saying we should do this *immediately*, but I think it's worth serious consideration if any not-SS14-adjacent projects are created in Robust Toolbox.
+
+We should also check Steam's policy for this sort of thing, as the SS14 launcher at this point would just be Robust Launcher in Game-specific Mode for SS14 (see below).
+
+### Game-specific Mode
+Obviously we can't just switch out the SS14 launcher on Steam for Robust Launcher, which is where Game-specific Mode (better name pending) comes in. Somewhere in the launcher build pipeline we will need the option to pass in a RobustHub game identifier which tells the launcher to launch in Game-specific Mode for that game.
+
+When operating in this mode, the RobustHub page is not accessible by default, instead the launcher opens directly into the page for the specified game. This would look practically identical to the current SS14 Launcher experience.
+
+However, buried deep in the launcher settings would be a setting for "Other Games Browser" or similar, which gives the whole explanation that the launcher is able to play other games made in the same game engine. Enabling this setting would still keep the game in Game-specific Mode and open straight into SS14 by default, but now the "RobustHub" page (which would normally be the default page outside of Game Mode) will be unlocked as an additional tab that they can easily navigate to. The purpose of this is so users whom are aware of this functionality don't need to have a duplicate Robust Launcher installation on their PC.
+
+Let's expand upon the hub diagram to incorporate launcher examples ([direct link](https://i.imgur.com/Kz5KM6Y.png)):
+
+
+
+#### Optional: Don't Hide Other Games
+PJB seems amenable to the idea of _not_ hiding the Other Games list by default when operating in Game-specific Mode.
+
+### Example UX
+Here's the process of joining an OpenDream server depending on whether you're using Robust Launcher or the redesigned SS14 Launcher (which is just Robust Launcher in Game-specific Mode for SS14). This assumes we do decide to hide other games by default in Game-specific Mode.
+
+#### Robust Launcher
+1. Start Robust Launcher
+2. Find and select OpenDream from the list of games
+3. Pick a server and join it
+
+#### SS14 Launcher
+1. Start SS14 Launcher
+2. Go to somewhere deep in the launcher settings
+3. Enable the "Other Games Browser" setting (only needs to be done once)
+4. Exit the settings menu
+5. SS14's main page now has a "RobustHub" or "Other Games" tab in the corner that players can select
+6. Find and select OpenDream from the list of games
+7. Pick a server and join it
+
+Quality-of-life enhancements like being able to pin/favorite certain games is subject to further design and bikeshedding.
+
+### Optional: RobustHub Game Jam
+
+Once RobustHub is fully implemented, we should advertise and then run a game jam (1-2 weeks) to develop new games (singleplayer or multiplayer) for RobustHub, unrelated to SS14. In addition to adding some variety to the games list, this will give us a chance to dogfood the system and also identify pain points in creating new Robust Toolbox projects.
+
+Depending on the level of interest, we could potentially offer prizes for the best submissions like a fancy Discord role and/or a $20 Steam gift card.
diff --git a/src/en/space-station-14/areas/core/accessibility/proposals/.gitkeep b/src/en/space-station-14/areas/core/accessibility/proposals/.gitkeep
new file mode 100644
index 000000000..e69de29bb
diff --git a/src/en/space-station-14/areas/core/admin-tools/proposals/.gitkeep b/src/en/space-station-14/areas/core/admin-tools/proposals/.gitkeep
new file mode 100644
index 000000000..e69de29bb
diff --git a/src/en/space-station-14/areas/core/art/proposals/.gitkeep b/src/en/space-station-14/areas/core/art/proposals/.gitkeep
new file mode 100644
index 000000000..e69de29bb
diff --git a/src/en/space-station-14/areas/core/character-species/proposals/.gitkeep b/src/en/space-station-14/areas/core/character-species/proposals/.gitkeep
new file mode 100644
index 000000000..e69de29bb
diff --git a/src/en/space-station-14/areas/core/combat/proposals/.gitkeep b/src/en/space-station-14/areas/core/combat/proposals/.gitkeep
new file mode 100644
index 000000000..e69de29bb
diff --git a/src/en/space-station-14/areas/core/mapping/proposals/.gitkeep b/src/en/space-station-14/areas/core/mapping/proposals/.gitkeep
new file mode 100644
index 000000000..e69de29bb
diff --git a/src/en/space-station-14/areas/core/player-interaction/grid-inventory.md b/src/en/space-station-14/areas/core/player-interaction/grid-inventory.md
new file mode 100644
index 000000000..c576ede2b
--- /dev/null
+++ b/src/en/space-station-14/areas/core/player-interaction/grid-inventory.md
@@ -0,0 +1,72 @@
+# Grid Inventory
+
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| EmoGarbage | :white_check_mark: Yes | https://github.com/space-wizards/space-station-14/pull/21931 |
+
+Credit to the SS13 server Fields of Fire, whose inventory overhaul served as inspiration for the UI.
+
+## Overview
+
+Grid inventory is intended to be a replacement for the current inventory backend and UI.
+It encompasses both an internal rewriting of storages, wherein they are classified by geometric shapes, as well as a redesign of the UI, aiming to translate the internal logistics of the system in an immediately understandable way.
+Under the system, storages will consist of grids made up of tiles and items will be small items that can be moved around and fit into the grid.
+
+## Storage Pains
+
+Laying out what's wrong with the current storage system is important, because inventories--and for the purpose of this document, inventory refers to any given storage container, not the players' hands and clothing HUD--fail in subtle and unexpected ways.
+The failures can be divided largely into two categories, mechanical and visual, and both show the unique ways in which a core system can underperform and in turn erode more central mechanics.
+
+In terms of the mechanical failings, those which call for the rewriting of the core of the system, the most evident is the inability to represent objects of unorthodox or strange shape.
+Whether it be a numerical size or an enum, it is impossible to communicate the spacial properties of something like a broom or a life preserver.
+Inventories cannot be long and thin or made up of many smaller sections.
+There is a lot of genuine interest in nuance in the problem of storing an object: it exists as a microcosm of greater questions of the value of what you carry and if it can be stored in an efficient manner.
+As the system exists currently, the "efficiency" of storage is not a concept that can be explored, which is a shame.
+
+On a more surface level, the presentation and interactions of a list inventory is also laden with issues.
+By existing as an infinitely scalable list, containers are forced to express the sizes and capacity numerically, relying on exposing objectively meaningless numbers in order to communicate scale.
+Furthermore, lists are bad at displaying images at a scale that is easily understood (due to their properties of being scalable) and thus rely on things like text, which simply saturates what should be a very simply HUD element with lots of text and numbers.
+Lists are also frequently used to fill up large chunks of the screen, which genuinely looks terrible.
+
+Ideally, a perfect storage system should not only be able to handle weird sizes and shapes of containers and items alike, but also visually convey this in a way that is immediately able to be understood by a new player without being overly reliant on text and numbers.
+
+Thing goes in bag is simple: it should feel simple to do.
+It should never feel sprawling or overwhelming or like you're scanning your screen for crap.
+
+## Grid Inventory
+
+Our solution? A to-scale HUD element that can represent uniquely shaped item's as well as display the size of things in an immersive and immediately understandable way.
+
+![](../../../../assets/images/grid-inventory/in-game.png)
+
+### Items
+
+Items in grid inventory are a deviously simple.
+They retain the ItemSize enum from the current system, but gain an additional `inventory shape`.
+This is just the shape the item takes up in the grid and it additionally serves to codify the hidden weight mechanics of the current inventory in a more intelligent way.
+Rather than tiny items having a weight value of 1, they simply take up a single square.
+Items would have reasonable default sizes inferred from the current weight values of items with an optional specifier for other custom shapes.
+
+![](../../../../assets/images/grid-inventory/shape-examples.png)
+
+Inside of the inventory, you'd be able to manually move around and rotate items, allowing gaps to be filled and space optimized with proper planning.
+You'd also be able to intuit how much of the inventory an item fills from a simple glance, since the volume is of the container is represented visually.
+
+### Storage
+
+![](../../../../assets/images/grid-inventory/grid-example.png)
+
+For the most part, storages exist as literal translations of the current values.
+A 28 capacity simply becomes a 7x4 box.
+In terms of balance, the numerical values of the different items and storages remains the exact same.
+The only difference is having to place the items into the bag and organize them to potentially make room.
+
+Of course, putting an item in your bag will automatically try and orient it within the grid, not allowing it only if there's no room for it to fit.
+This means there's an equal measure of convenience in terms of picking items quickly, only being a hindrance when trying to fit an unwieldy object.
+
+The hotkeys for quickly taking items in and out of bags will remain identical, simply remembering the order of inserted items and taking them out in the reverse order.
+
+### A Brief Aside About Slots
+
+For slot-based storage, like belts, the UI will remain the same, but simply with standardized item sizes.
+A 7 slot belt is a container with 7 squares and every item takes up only a single square. This loses out on the benefits of the scaling, but it integrates well enough and conveys the same information as the previous system, so it's kinda moot.
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/core/player-interaction/proposals/pda-messaging.md b/src/en/space-station-14/areas/core/player-interaction/proposals/pda-messaging.md
new file mode 100644
index 000000000..64563c647
--- /dev/null
+++ b/src/en/space-station-14/areas/core/player-interaction/proposals/pda-messaging.md
@@ -0,0 +1,115 @@
+## PDA Messaging
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and has not been reviewed or updated.
+It may not fit with the new department design requirements.
+```
+
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| Julian & VasilisThePikachu | :x: No | TBD |
+
+*(Taken by [Julian doc](https://hackmd.io/iu2yK9bcQb-veuCOLl-FYw?both#Optional-Channels-and-Department-based-Channels) in hackmd and modified a lil. Mostly replacing "email" to "message", "Email address" to "user/user id" and adding some of my own twists. Julian was fine with this if i understood correctly (i was in vc with em))*
+
+*(This is mostly taken from how PDA messages work in ss13)*
+Allows sending messages to others using PDAs
+
+### What this adds and why
+Simple, Messaging via the PDA!
+Messaging someone via the PDA should be made when you need to get the attention of a special someone. Example as HoS you want to ask detective to come over to investigate an item. It's easier to get their attention cause of their PDA vibrating then hoping they are monitoring their channel. Another usage is the heads planning Captain a suprise birthday party. Something like that would require all heads getting together in one place.
+
+This is **not** a replacement to the radio channel. Theres no "common" channel, it would be easier to spoof being someone (just need their id), past messages on that same id can easily be exposed and its far more cumbersome to message someone over PDA then just using the radio.
+
+### Message storage
+Messages are stored on a server most likely will be stored in telecoms. There can be one server per station, others on the same station won't be used unless the first one loses power or gets destroyed.
+
+*Optional* The active server synchronises itself with all of the inactive servers on the same station (This happens inside the system directly, no device networking here).
+
+### One active / Multiple inactive server model
+
+(This talks about some refactor stuff and Julian told me they forgot to paste the link, im keeping it to be safe in case its actually useful.)
+
+The one active / multiple inactive server model uses the system that will get refactored into its own system from the crew monitoring server [link text]()
+
+The messaging client system will use the `GetActiveServer` method of the message server system to retrieve the active server if the client doesn't have a server set yet or that server timed out. *This is also from the system that gets refactored out.*
+
+### Sending and receiving messages
+
+When sending a message to someone via the program the PDA sends the message together with an 'user id' to the server and the server will send the message to the target device. Of course there will be a character limit (say... 100 characters?)
+
+When a PDA recieves a message it plays the PDAs ringtone and vibrates, showing the sent message on the chat. This message can also be viewed on the PDA via a program.
+
+Notifications can be disabled if desired.
+
+This user id could be generated into the ID card so that if you get a new PDA your messages are kept as long as you are using the same ID card. Late joiners will get assigned a uid when they arrive on the station. Potencially HoP or RD can move your UID to the a new ID card with the ID comnputer rendering the old ID card useless. This can also prevent powergaming by someone changing their UID to see others messages.
+
+This UID will receive messages for as long as it is in the station and in a PDA.
+
+If its not in station the messages can either fail to send or be added in a queue to be sent when it reenters the station.
+
+Since the UID is stored on the ID. That means that if you manage to get your hands on someones ID you can chat as them and potencially (if added) read their messages.
+
+### Users list
+
+When opening the PDA messaging app, you will be able to start a chat session with everyone connected to the server (aka everyone with a PDA)
+
+They will be listed by name and job title like this "Vapor-Tail (Captain)"
+
+*Optional* Add the ability for people to not be allowed to initiate a conversation with an option. This can be useful for high command staff like captain from getting message spammed by clown and others at the start of the shift.
+
+### Optional: Detomatix PDA Cartridge
+
+(find the original item in the tg wiki here: https://tgstation13.org/wiki/Syndicate_Items)
+
+The detomatrix is... a zip bomb in easy to say terms. Allowing you to send a spoofed message that when opened by the target fast enough bricking the PDA and its ID (instead of exploding... even though thats funnier maintainers please allow this)
+
+It will have a chance to fail and have an even lower chance of working on "high profile" PDA's like the Captains.
+
+It could be used as a way to get people to turn off their messanger function in fear to not being up next if someone screams in radio about it and could be useful.
+
+### Optional: Multiple network support
+
+The server is able send on the wireless and the wired network because it saves what network the registered devices are on along with the user id and the network address.
+
+This requires devices to be able to register themselves with two device net ids at once (which should only be done if it is really needed).
+
+### Optional: Channels and Department based Channels
+Channels are special groups that relay the messages sent to them to users who are subscribed to that channel.
+
+Channels can be created and they can be deleted by the channel creator.
+
+When registering to a server the client also sends the job of the inserted ID so the server can put them into special department channels.
+
+Department channels can't be joined, left or deleted.
+
+### Optional: RDs messager admin management console
+The research director and potencially Captain get a console which connects to the message server via device net that can be used to view and manage all messages and groups.
+It uses device net with an `AccessComponent` on the message server so the management functions can be hijacked by traitors that got their hands on an ID card with the right access. (This requires [device net access restrictions](https://hackmd.io/gPjP95_zRUiT-bX4hKxE6w) to be implemented.
+
+### Optional: pAI as a chat assistant.
+This will add new gameplay for the pAI ghost role. Allowing the pAI to chat as their master on their behalf. Could have a little pAI icon in the chatbox to show it was sent by the pAI and not the actual player. pAI's for a while have been kinda boring and may deserve their own design doc of ideas but this is one of my ideas that come to mind.
+
+
+### Concerns
+When initially asked about this I was met with some concerns. This section is to address them
+
+Discord discussion start: https://discord.com/channels/310555209753690112/310555209753690112/1160244698112327830
+
+##### Why PDA messaging over plain radio? Would this upset radio balance and reduce coms over radio?
+First of all why:
+If you play the game you can quickly realise how getting someone's attention god forbid multiple, can be... not an easy task to say the least. You either are lucky and the person you want is just so happening to be monitoring the chatbox or they are busy and not paying attention. In the end missing your message until you resend it or try to look with them. This is just not fun and is just annoying. PDA messaging can solve this.
+
+As to if it will upset radio balance: Highly unlikely it will be. Mostly cause:
+1. PDA messaging wont let you get the attention of multiple people at once (common). PDA messaging can reach one person at the time (unless we get department groups but even then). You will have to jump through a lot of hoops if you JUST wanna use messaging. Radio is easier and faster to talk into and gets to multiple people at once.
+2. Sending a PDA message is more of a chore then just using the radio channel, PDA messaging will at least need a minimum of 6 steps to open the PDA, go to the app section, start the app, find the person, write the message and send. And if you keep the chatbox on it would just take up a good chunk of your screen. Or you could just do ":c Captain hamlet ate uranium"
+3. Messages are stored and logged. Someone steals caps PDA? Well now all of their messages are up on display. With radio unless they had command channel already they would never learn of any past messages. If two syndies decide to use PDA messaging rd can just grab their chatlogs. Same with syndies using it to communite with others.
+4. PDA messaging has a pretty small character limit, if you wanna say something long radio is the place.
+
+May be the wrong section but admins can also use this to act as "Central Command" so instead of having to subtile message someone they can just send a message to their PDA.
+
+##### It reduces everyone else's situational awareness since people can't see all radio messages anymore.
+I highly disagree, I doupt it will reduce situational awareness more then it already is. I have already went over how someone monitoring the radio channel for messages directed to them is already a chore. PDA messaging names can easily be changed by using someone elses ID therefore its a good idea to not go to maints like they told you to and instead show the message to security.
+
+##### Why not use fax?
+Is this really a question? First of all not everyone has a fax, second you have to be close to hear it go off printing. And unless you check your fax periodicly for new faxes messages can be missed. And even if you do check it its probably boykisser ASCII spammed 10 times. Also why are we using *faxes* in 2563 or whatever year SS14 takes year in.
+
+These were all the conserns I could find from discord.
diff --git a/src/en/space-station-14/areas/core/roleplay-lore/proposals/.gitkeep b/src/en/space-station-14/areas/core/roleplay-lore/proposals/.gitkeep
new file mode 100644
index 000000000..e69de29bb
diff --git a/src/en/space-station-14/areas/core/round-flow/antagonists/exterminator.md b/src/en/space-station-14/areas/core/round-flow/antagonists/exterminator.md
new file mode 100644
index 000000000..9e3c3cf99
--- /dev/null
+++ b/src/en/space-station-14/areas/core/round-flow/antagonists/exterminator.md
@@ -0,0 +1,47 @@
+# Exterminator
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and has not been reviewed or updated.
+It may not fit with the new design requirements.
+```
+```admonish warning "Possible Removal"
+This content is being considered for removal, and may no longer be in-game in the future.
+```
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| deltanedas | :white_check_mark: Yes | https://github.com/space-wizards/space-station-14/pull/19946 |
+
+## Abstract
+
+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.
+
+## Goals
+
+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.
+
+
+## Gameplay
+
+While the exterminator has no telecrystals or gear like syndies or ninjas, what they do have is the following:
+
+- 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.
+- 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.
+
+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.
+
+As it only spawns without intervention through a midround event, it can never spawn or have multiple exterminators per round.
+
+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.
+
+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.
+
+## Components
+### Endoskeleton
+
+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.
+
+As the endoskeleton can’t hold guns and is slow, it is an easy target for tiders to finish off with bats and crowbars.
+
+
+## Inspirations
+
+Obviously The Terminator (1984) it’s a classic.
diff --git a/src/en/space-station-14/areas/core/round-flow/antagonists/thief.md b/src/en/space-station-14/areas/core/round-flow/antagonists/thief.md
new file mode 100644
index 000000000..ccfe912b7
--- /dev/null
+++ b/src/en/space-station-14/areas/core/round-flow/antagonists/thief.md
@@ -0,0 +1,103 @@
+# Minor Antagonist: Thief
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and has not been reviewed or updated.
+It may not fit with the new design requirements.
+```
+
+the purpose of this proposal is to add a new minor antagonist to the game, the Thief.
+This antagonist's specialty is stealing various items, structures and animals from the station, without resorting to violence or killing.
+
+## Appearance
+Thieves is a small addition to the other game modes. At the moment, thieves can only appear in Traitors and Revolution modes with 50% chance. There can be from 1 to 3 thieves in total, and they are chosen among random players at the beginning of the round. The exceptions are Command and Security players.
+
+When appear, the Thief gains 1 new item, "undetermined toolbox", which allows you to choose your play style by giving you starter gear.
+
+## Customizable play style
+Inside the Thief's backpack, there are 3 things by default:
+1) Thief's Gloves, which allow you to steal things from people unnoticed
+2) Undetermined toolbox, allows you select up to 2 starter equipment kit
+
+Suggested equipment sets for toolbox:
+| Name | Content |
+|----------|:-------------|
+| Thief Pinpointer | Includes: A pinpointer that shows the direction to an object of interest to the owner thief. When switched on or off, it selects a random object for which the thief has not yet completed the target. |
+| Chameleon's Set | Includes: A set of chameleon clothes. |
+| Bearcatcher's kit | Includes 2 C4s, multitool, jaws of life, advanced welder meson glasses and insulated gloves.|
+| Chemistry kit | It includes a storage implanter, a dna scrambler implanter, and ephedrine bottle, omnizine bottle.|
+| Syndie Set | Includes: Agent ID, syndie-cigarettes, syndie pAI, 10 TC (usless for thief, needed for traitor. Communication?)|
+| Sleeper Set | Includes: a hipopen, a set of 3 nocturine vials, a nitrous oxide cylinder, a set of syndicate pajamas. |
+| Communicator's kit | Includes master key for all station channels, radio jammer, voice mask, portable crew monitor and lots of money for business deals. |
+| Smuggler's kit | Includes a fulton beacon, 10 fultons and invisible crate. |
+
+## Thief goals
+The thief's targets are chosen according to the following pattern:
+With a 50% chance, a difficult target is added to steal a structure or animal. The remaining targets are selected from a pool of small item theft or collection targets until the total difficulty is sufficient. The final goal is always to escape the station alive and unarrested.
+
+### Steal the item
+The goal is to steal a certain item from the station, and keep it with you by the end of the round.
+The target list consists of random objects whose abduction can lead to interesting scenarios. This list can include both easy and extremely difficult targets.
+This list should not include items that Traitors require: if they are successfully stolen by a thief, the goal becomes too difficult for the Traitor to accomplish.
+
+| Item |
+|------|
+| Forensic Scanner |
+| AmmoTechFabCircuitboard |
+| ClothingHeadHatWarden |
+| ClothingOuterHardsuitVoidParamed |
+| MedicalTechFabCircuitboard |
+| ClothingHeadsetAltMedical |
+| RnDServerMachineCircuitboard |
+| FireAxe |
+| RCD |
+| AmePart |
+| ExpeditionsCircuitboard |
+| CargoShuttleCircuitboard |
+| SalvageShuttleCircuitboard |
+| ClothingEyesHudBeer |
+| Bible |
+| ClothingNeckGoldmedal |
+| ClothingNeckClownmedal |
+
+
+## Steal the structure
+the goal is to steal a large object that doesn't fit in your inventory. For the goal to be fulfilled, the structure must be near the thief at the end of the round.
+
+| Structure |
+|-----------|
+| Nucler Bomb |
+| The captain fax |
+| Security Segway |
+| Chemical Dispencer |
+| Alien artifact |
+| Heater or Freezer |
+| Teg part |
+| Meat Spike |
+| Hydroponic tray |
+| Booze dispencer |
+| Altar |
+
+## Steal the animal
+The goal is to steal and have said animal next to you by the end of the round. The animal must be alive.
+
+| Animal |
+|--------|
+| any animal with a name (except Ian) |
+
+## Collecting
+the goal is to accumulate a large number of specific items and have them with you by the end of the round.
+
+| Item |
+|------|
+| Head's Cloaks |
+| Head's Bedsheets |
+| Stamps |
+| Door Remotes |
+| Research Disks |
+| Figurines |
+| ID Cards |
+| Cannabis |
+
+## Expected gameplay
+Given the restriction on violence, gameplay as a thief involves maximum stealth. The thief evaluates the quests he has received, and chooses 2 sets of items to choose from that can help him best. The thief tries to steal the specified targets stealthily, trying not to get caught. If caught, the thief may not fight. But even the specified list of targets does not allow the security service to execute him or put him permanently in a cell.
+
+This means that a thief, once released, can always try again.
diff --git a/src/en/space-station-14/areas/core/round-flow/proposals/cleanup-crew-gamemode.md b/src/en/space-station-14/areas/core/round-flow/proposals/cleanup-crew-gamemode.md
new file mode 100644
index 000000000..45865af25
--- /dev/null
+++ b/src/en/space-station-14/areas/core/round-flow/proposals/cleanup-crew-gamemode.md
@@ -0,0 +1,56 @@
+# Cleanup Crew
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and has not been reviewed or updated.
+It may not fit with the new design requirements.
+```
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| mirrorcult | :x: No | TBD |
+
+## Overview
+
+Cleanup Crew is a lowpop (0-20 players) gamemode built around the concept of repairing destroyed stations from previous rounds. The goal is to provide a fun, relatively chill experience that differs from the base game but still interacts with all of its systems (especially construction, power, atmos, etc), acting as an educational experience, while also being very atmospheric.
+
+The NanoTrasen Emergency Cleanup Crew, one spacemonth after the sudden abandonment of their finest new station, will start the game on a medium-large ERT shuttle near the disheveled station. The shuttle is stocked with everything you could need--lots of materials & RCDs, medical supplies, atmospheric supplies, generators, janitorial equipment, etc.
+
+Each cleanup crew member has a designated role (atmospherics, power, repair, janitorial, security, etc) but they can of course branch into doing anything as needed with their supplies. The goal of the cleanup crew is to ensure:
+
+- the station's tilemap is as close to the original station's tilemap as possible
+- as many of the original tiles have viable air as possible
+- the new station has as many of the same machines as the old station, and that as many of them are powered as possible
+- as few spills, blood & dirt remain as possible
+- as many "intruders" are eliminated as possible
+
+The cleanup crew is given a time limit of 1-3 hours (depending on how large the map is & its chaos value), after which they must FTL away inconspicuously to evade detection by the Syndicate.
+
+## Intruders
+
+As mentioned before, the map is mostly kept unchanged from the saved version, but it *has* been a whole spacemonth!
+
+It's possible that some hostile fauna (and some decorative flora for that rundown feel) have moved in. These can include:
+
+- Xenos, which will have spawned resin walls and eggs randomly
+- Spiders, which will have spun lots of webs and nests
+- Carp & sharks, which will be scattered around the station with a dragon or two sprinkled around
+- Orecrabs, with corresponding rock deposits that must be cleared out
+- Nothing! No one got there before you did. A chill experience
+
+Only one class of intruders is selected for the whole station, and they (along with any infrastructure they bring with them) are procedurally dotted around the station in clusters or in singular surprise instances.
+
+The cleanup crew comes loaded with plenty of medical supplies and !!FUN!! pulse & powerful ballistic weaponry, so these aren't generally much of a real threat, but they do make for a more dynamic experience.
+
+## Scoring
+
+The cleanup crew, at the end of the round, is scored based on the factors mentioned above. The score is compared to how the original station would have scored, and some flavor text is displayed congratulating or disparaging the cleanup crew on their hard work.
+
+## Map Saving Mechanic
+
+To elaborate on how the maps are selected:
+
+After any round finishes on some server, a quick heuristic "chaos value" (power, atmos, tiles missing) is calculated to evaluate how "destroyed" a station is. If the chaos value is high enough (but below a certain critical threshold of too much destruction), the map is saved, with some annoying entities removed (all mobs are replaced with skeletons, for example), and then stored as a blob in the DB to be used later.
+
+Up to ~20 (maybe less, maybe more) stations can be saved at a time, and when a cleanup crew gamemode spawns, one is removed from the list and loaded in. If a map cannot be loaded, another is tried, until there are none left in the list. If there are no viable maps for cleanup, the gamemode is unavailable for play.
+
+After the map is loaded, a short procedural pass spawning random mess decals and flora such as trees and bushes or vines is done. Afterwards, if an intruder (see above) was selected, they are spawned in as well.
+
+Some scenarios, like a nuke going off after nukies, will mark the map as unable to be saved for cleanup crew, since it's obviously a bit too much of an outlier.
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/core/round-flow/proposals/game-director.md b/src/en/space-station-14/areas/core/round-flow/proposals/game-director.md
new file mode 100644
index 000000000..589a5ad23
--- /dev/null
+++ b/src/en/space-station-14/areas/core/round-flow/proposals/game-director.md
@@ -0,0 +1,215 @@
+# Game Director
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and has not been reviewed or updated.
+It may not fit with the new design requirements.
+```
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| tom-leys (RecallSingularity) | :information_source: Open PR | https://github.com/space-wizards/space-station-14/pull/16548 |
+
+## Overview
+
+Triggers game events to attain a chaos goal. Goal varies during each round to create variety.
+By measuring and varying chaos, the director keeps the challenge each round within a fun band. It reacts to player success
+or failure by tailoring future events based on current chaos measured.
+
+The Game Director adds new game modes, initially CombatDynamic and CalmDynamic. They can only be triggered by an admin
+running for instance `addgamerule CalmDynamic`. A later PR could put them into automatic rotation.
+
+## Background
+
+Events in SS14 trigger challenges or benefits for players. They might spawn spiders, dragons or zombies. Traitors
+come on board, Nukies attack or vents spew grease. Pizza might be delivered or power is turned off to sections of the station.
+
+Historically events trigger in a few ways:
+
+- At round start (for instance a zombie or nukie round begins)
+- Randomly, every 5 minutes or so (extended rounds)
+- Randomly, at an increasing pace (survival rounds, now discontinued)
+- Due to admin commands such as `addgamerule`
+- Hand created by admins adding entities and using admin tools.
+
+In the absense of administrator intervention, extended rounds can become boring and monotonous. Zombie or Nukie rounds
+are often boring for a period, intense for a period and if the station is saved boring again.
+
+Due to the random nature of the extended round system, events cannot be too dangerous or too beneficial to the players
+or through RNG they are likely to trigger at the worst time. One station might be flooded with spiders, a dragon and space lube
+under every vent while another only suffers a few rats and some flickering lights.
+
+The Game Director aims to provide an alternative to the extended mode that is flexible and drives a fun set of events
+towards a larger set of Chaos Goals. A wide array of extreme events both positive and negative can then be added to the game
+safe in the knowledge they will be run at suitable times rather than randomly.
+
+Discord Topic: https://discord.com/channels/310555209753690112/1110002801448329226
+GitHub PR: https://github.com/space-wizards/space-station-14/pull/16548
+
+### Car Metaphor
+
+Imagine you are driving on the highway. You look at the metric of your speedometer to see how fast you are driving. The
+speed limit specifies how fast you should go. You then pick either the apply gas, reduce gas or turn on radio events to
+best match the car speed to the goal set by the speed limit. The director works in a similar way.
+
+## Basic method
+
+- **Chaos** - Metrics we are measuring and controlling with each event
+- **Story** - Determines a series of Chaos Goals
+- **Metrics** - Estimate the existing chaos on station
+- **Events** - Have a predicted effect on chaos
+- **Game Director** - Pick best Event to achieve story Metrics
+
+1. **Wait** until it is time for next event
+2. Run **metrics** to measure current **Chaos**
+3. Advance **StoryBeat** and **Story** (over time or based on Chaos)
+4. Read **desired Chaos** from **current StoryBeat**
+5. **Rank** valid events to achieve near desired chaos
+6. Run **best event**
+
+## Chaos - Metrics of a station
+
+We want to measure how bad the Chaos is right now. If the station is doing well, the lights are on and the floor is clean,
+we expect low chaos scores. If the lights are out, the place is spaced and enemies are roaming the station, we want high
+chaos scores.
+
+To best tailor events to the exact situation on the station, chaos is measured by several metrics.
+The solution to hunger is pizzas. The solution to enemies might be a squad of reinforcements. A station
+that is too peaceful is ready for meteorites, spiders or other hazards.
+
+A wide range of challenges should be reflected by moderate chaos values for every metric to best challenge all departments
+on the station. For instance many new anomolies will keep science busy and potentially annoy other players. But anomolies won't
+tax security the same way traitors or spiders would.
+
+Obvious metrics, where a perfect station has chaos of 0 and it increases as things get messy:
+- Hunger
+- Thirst
+- Anomaly
+- Death
+- Medical
+- Security
+- Power
+- Atmos
+- Mess
+
+Combat metrics:
+- Friend - negative to represent how many friendlies are alive on the station
+- Hostile - Score for all antags and monsters
+- Combat - Friend + Hostile. <0 if crew is strong. 0 if balanced (fighting). >0 indicates crew is losing.
+
+## Story - Determines a series of Chaos Goals
+
+Stories are composed of StoryBeats and determine the Chaos Goals over a 15-30 minute period within a round.
+
+Beats generally last 5 minutes each, though they might end early if chaos hits certain thresholds.
+These are called `endIfAnyWorse` and `endIfAllBetter`, useful if there is too much war, or perhaps too much peace.
+
+Once a story beat has ended, the director will move to the next beat in the story. Once a given story has finished, the
+director will pick one of its stories at random to start.
+
+Player experience in SS14 should have both its highs and lows. A peaceful extended shift can become boring with no challenges
+to overcome together. An overly intense battle might kill half the crew and leave the station in disorder that we cannot recover from.
+What we want is a middle ground with some variation.
+
+The ideal story has a mix of both, with order followed by disorder and then a chance to recover and rebuild. We want variety with
+pleasant cycles in intensity potentially building towards an overall climax as the round progresses.
+
+### Dynamic Game Modes:
+
+Each game mode preset specifies which stories will run and so determines the tone for the experience created by
+the director.
+
+The number of stories and story beats is quite small right now, as we add more content to the game we will also expand
+the range of stories followed by the director to increase the tonal variety between rounds.
+
+#### CombatDynamic
+Contains combat stories and so will create a station with some fighting
+- **RelaxedAttack** - Peace -> AttackMild -> EngineeringIssues
+- **ScienceAttack** - Peace -> MadScience -> AttackMild -> Peace -> EngineeringIssues -> RepairStation
+- **MajorCombat** - Peace -> AttackMild -> EngineeringIssues -> Attackers -> RestoreOrder -> RepairStation -> Peace
+
+#### CalmDynamic
+More like an extended round, has a balance of minor chaos events
+- **Relaxed** - Peace -> AttackMild -> EngineeringIssues
+- **Science** - Peace -> MadScience -> Peace -> EngineeringIssues -> RepairStation
+
+### Story Beats
+Some beats deliberately drive moderate or high chaos for a period of time. Others bring specific types of chaos to near
+0 to encourage the director to pick helpful events until the station is moderate again.
+
+The hostile story beats tend to end if the station chaos rises too high. The recovery ones end if the chaos drops low
+enough. By incorporating both into a story we can expect some hostile events, a period of chaos followed by positive
+events and a period of recovery.
+
+- **Peace** - Minor Chaos across a wide range
+- **PowerIssues** - Create high engineering chaos
+- **MadScience** - Create high Science chaos
+- **Attackers** - Drive high combat
+- **AttackMild** - Drive medium combat
+- **RestoreOrder** - Send help to quell disorder on the station
+- **RepairStation** - Repair that station
+
+## Metrics - Estimate the existing chaos on station
+
+A number of systems called "Metrics" are used to summarize the chaos levels. Metrics each stand alone and so it will be
+easy to add or remove them as the game matures.
+
+Metrics could subscribe to relevant events and dynamically adjust their scores as events occur on the station. Or they
+can do a single pass through the component system when run. The single pass approach has been preferred in favor of its
+stability and simplicity for now.
+
+#### Metrics at the moment
+- **AnomalyMetric** - Are there many? Are they out of control? Writes to "Anomaly"
+- **CombatMetric** - Who is on the station? How injured are our friends? Writes to "Hostiles", "Friendlies", "Death" and "Medical"
+- **DoorMetric** - Uses doors as a proxy to surveying the ship for danger. Writes to "Security", "Atmos" and "Power"
+- **FoodMetric** - How hungry are the friendly crew? Writes to "Hunger" and "Thirst"
+- **PuddleMetric** - How messy is the station (partially as a proxy for safety). Writes to "Mess"
+
+I expect that as we describe a situation we want the Director to react to we will introduce further metrics to give us
+richer insight into the station. We might want trust metrics based on how many traitors there are. Or staff / department
+metrics based on staffing issues and role deaths.
+
+## Events - Have a predicted effect on chaos
+
+How do we describe what an event does?
+
+Events have a metric called "Chaos" which describes different types of negative effects they bring to the station.
+Good events cause negative chaos.
+
+If our chaos estimates for each event are accurate, the game director can easily control chaos by picking the best events
+for the current story beat.
+
+### Negative events increase chaos
+SpiderSpawn:
+ - Hostiles: 40 - New hostiles are introduced
+ - Friends: 20 - Friends are likely to die
+ - Medical: 150 - Medical will have wounds to heal
+
+### Positive events reduce chaos
+PizzaPartySmall:
+ - Hunger: -80 - The pizza party satisfies hunger
+ - Thirst: -40 - And also thirst
+
+## Game Director - Pick best Event to achieve story Metrics
+
+Each of the **story beats** from above has a matching chaos level, specifying factors that we care about at that point
+in the story along with target values for those **Chaos factors**.
+
+Once we know what **Chaos metrics** we currently attempting to achieve, we have a chance to select the correct event.
+
+- The **Story Beat** has told us what chaos we want.
+- The **Metrics** tell us what chaos the station currently has.
+- Each **StationEvent** has a Chaos field predicting that event's impact
+
+So we iterate through all the possible events, choose the one which moves the station chaos nearest to our goal and set
+that event into action. Simple!
+
+The whole process is richly logged into the admin log (under GameDirector) so the admins have insight into what the director
+is attempting to achieve.
+
+# Conclusion
+
+The Game Director system will allow us to author specific experiences that are gated on how chaotic the station has become.
+
+The more events we introduce to the game with clear chaos outcomes, the better the system will be at guiding the station
+through a specific narrative experience.
+
+The data driven nature of the metrics and story data means that a wide variety of narrative outcomes and station-specific
+events can all be achieved through the same system.
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/core/round-flow/proposals/pizza-delivery-critter.md b/src/en/space-station-14/areas/core/round-flow/proposals/pizza-delivery-critter.md
new file mode 100644
index 000000000..63bf1edc2
--- /dev/null
+++ b/src/en/space-station-14/areas/core/round-flow/proposals/pizza-delivery-critter.md
@@ -0,0 +1,87 @@
+# Arnold's Pizza Delivery Service
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and has not been reviewed or updated.
+It may not fit with the new design requirements.
+```
+| Designers | Implemented | GitHub Links |
+| -------------- | ----------- | ------------ |
+| FairlySadPanda | :x: No | TBD |
+
+# Arnold's Pizza Needs Delivery Critters
+
+- Alone?
+- Gullible?
+- Poor?
+- Unaware of our reputation?
+
+If most/all of these apply to you, _or_ we've successfully kidnapped you from your home, then Arnolds Pizza has a job with your name on it!
+
+We need delivery critters willing to do one of the most difficult and thankless tasks in known space: delivering pizzas to NanoTrasen employees!
+
+NanoTrasen knows we make the best pizza in the galaxy*. That's why they have an exclusive contract with us to fulfil their Random Reward Pizza employee satisfaciton scheme. However, NanoTrasen's boutique, black-ops and (frequently) badly-maintained space stations are both challenging to access and deliver to. The fell-off-a-back-of-a-van BlueSpace teleporation devices that we use for such challenging customers are both extremely unethical *and\* have a carry-limit small enough that we can't send a full-sized sapient creature through with our KeepWarm pizza boxes in tow!
+
+That means there's a _unique_ and _exciting_ opportunity for small, light, _expendable_ critters in our delivery services. Join today, and we promise that we'll let you leave afterward. Just remember to get that receipt!
+
+\*As do the Syndicate, but we don't tell them that.
+
+# Overview
+
+Building on positive player feedback from the April Fools Legally Distinct Space Ferret neutral antagonist, this design document outlines a role that sees the player play as a small, agile critter on a time-limited mission to complete a delivery task to a member of the crew. Success is delivery and retreival of a signed receipt: failure is a tragic death due to the compromising of the nuclear fission heater that the delivery company has strapped to said critter's back.
+
+## Player Profiles
+
+- **Pop-In** wants to pop-in to to the round for a few minutes and interact with the crew, but doesn't have time to stick around for the evac shuttle.
+- **Cutesy Gamer** wants to play as a cute critter with more than just roleplaying to do.
+- **Comedy Gamer** wants to be placed in a tense, absurd situation where their game knowledge can shine to get a challenging goal done.
+
+## How it works
+
+- A mid-round ghost role of "Pizza Delivery critter" allows a player to spawn as a cute sapient critter similar to a monkey or kobold at appropriate spawns decided by the map creator, or by mimicing vent critter spawning should this retrofitting have not taken place.
+- This critter is given two sets of information:
+ 1. The identity of its delivery target, including their face, profession and name.
+ 2. The amount of time they have to complete the delivery before the KeepWarm heater on their back violently explodes.
+- The timer is constantly displayed at the bottom of the screen, above the equipment bar. This is a reference, appropriately enough, to _Pizza Tower_.
+- The critter is a neutral antagonist with one objective:
+ - Get a signed reciept from the target before time runs out.
+- The critter's target must be alive and not in crit to be chosen.
+ - If the target is gibbed or becomes SSD for any reason during the delivery attempt, Arnold's Pizza declares the order void and the player is freed from the timer. If this happens, they get to eat the pizza. This is the "neutral" end condition for this antag - the player will not greentext, but they do not get round-removed.
+- The critter the player plays at has the following abilities:
+ - Small creature hitboxes, allowing it to slide underneath most doors. Arnold's Pizza has extensive experience dealing with NT stations and has engineered its delivery critters to be able to actually have a chance of delivering to Urist McScientist who is sitting behind three secure airlocks.
+ - The following item slots:
+ - Hat (containing a branded red Arnold's Pizza cap that itself contains a tiny item storage slot, containing a pen)
+ - Mask
+ - Belt (containing a branded o2 canister)
+ - Pocket (with a branded gas mask)
+ - PDA/ID Card
+ - One hand slot
+ - The critter is not especially vulnerable to any damage type, breathes oxygen, but has no capacity at all to wear a spacesuit. They are provided with the means to survive atmos failure, though, preventing frustrating spawns.
+ in the event the station is spaced, but they will die to barotrauma somewhat quickly.
+ - The critter has the same amount of health as a monkey.
+ - The critter nyooms - that is, they have a higher-than-average base and running speed, appropriate for a frantic delivery vehicle.
+ - The critter only speaks in cute noises unless given cognizine.
+- The critter has the ability to print out a receipt for its order. This receipt contains the same information the critter was given regarding the target's identity.
+- The receipt has a space for a signature. The only way this signature can be filled in is by the target. It needs to be filled in by using a pen (of any kind) on the receipt.
+- The receipt must be handed back to the critter, who then must feed it back into the heater to retrieve the pizza. This counts as a victory and allows the critter to greentext.
+- The pizza is one of Arnold's specials. The pizza will have one of the following properties:
+ - Dank: contains, as you'd expect, dankness, and gives the user hallucinations (cannabis).
+ - Healthy: like the current Arnold's pizza item, this contains a powerful healing agent (omnizine).
+ - Stimulants: this pizza is loaded with sugar and makes the target nyoom for a medium period.
+ - Hot N Spicy: eating the pizza causes the target to set on fire.
+ - Space Carp Pizza allows the target to avoid pressure damage for a medium period.
+ - Classic: (PRE WOUND MED) causes the target to detonate. (POST WOUND MED) causes the target's limbs to fly off.
+ - All of these pizzas have a "paper-oni" pizza variant for moths to eat.
+- The pizza types have clear labels on their boxes and unique descriptions, but do not overtly say what they do. The positive-effect pizzas are weighted more likely to appear than the negative ones, with the Classic pizza being a rare chance.
+- If the critter fails to deliver the pizza in the time limit, it explodes. This explosion is faked - it gibs the critter but convers no damage to anyone else standing nearby, even on the same tile, to prevent this feature being abused to suicide bomb people.
+- It is possible for a member of the crew with bomb disposal knowledge to disable the KeepWarm heater, thus saving the critter's life. If this occurs, the critter cannot greentext.
+- If the target is in crit or cuffed, using the printed receipt on them whilst the critter has a pen in their pocket allows the critter to forge the signature, greentexting.
+- If the critter has delivered its pizza, it can become eligible to deliver another pizza again later in the round provided the pizza delivery event is rolled again (or if an admin is feeling cruel).
+- The critter always has the option of aborting the mission and teleporting back off the station, to avoid feel-bad moments where the objective is undeliverable, the station is in too bad a state to attempt a delivery, etc.
+
+## Traitor/Nukeops Gameplay
+
+- The Syndicate also have an exclusive contract with Arnold's Pizza, and they leverage that to do a little trolling and help themselves out.
+- A traitor or nukie can order a pizza delivery for themselves or a member of NanoTrasen crew. If they do this, they can specify what exactly the critter is going to deliver. This includes a new, exciting flavour: a bomb with a fuse that looks like it fell out of a Looney Tunes cartoon. The bomb is much too heavy for the critter to hold, and they drop it immediately.
+- This bomb detonates a few seconds after the critter has retrieved it from its KeepWarm heater, doing moderate damage to the station in the process.
+ - This is a reference both to Looney Tunes and the famous "sometimes you just can't get rid of a bomb" sketch from the Adam West Batman TV series.
+- The critter is not told they are delivering a bomb or that they're working for the Syndicate, and there's no metagameable way to know if a pizza delivery is legitimate or a trap.
+- This mechanic makes sure that there's a theoretical reason that a player may refuse a delivery.
diff --git a/src/en/space-station-14/areas/core/round-flow/proposals/rogue-drones.md b/src/en/space-station-14/areas/core/round-flow/proposals/rogue-drones.md
new file mode 100644
index 000000000..8deb4ab08
--- /dev/null
+++ b/src/en/space-station-14/areas/core/round-flow/proposals/rogue-drones.md
@@ -0,0 +1,71 @@
+# Rogue Drones
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and has not been reviewed or updated.
+It may not fit with the new design requirements.
+```
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| mirrorcult | :x: No | TBD |
+
+
+
+## Background
+
+rogue drones is kind of a placeholder name its not that good we can come up with something better or just call them swarmers who caaaaares
+
+---
+
+On some SS13 servers, an antagonist called the **swarmer** exists (or existed, as it was disabled in some places). It's goal was to destroy machines & structure around the station and convert it into material to create more swarmers with. Essentially grey goo. They had extremely limited combat capabilities (mostly traps & stuns) and are generally hated for being extremely annoying, disruptive, and overly centralizing.
+
+**Drones** also exist on some SS13 servers, and even on SS14 for a time (disabled for being too much of an admin burden). They're not antagonists, and are intended to just be a little ghostrole that tries to repair the station and keep itself out of the way of the crew. Because of this, they end up being weirdly restrictive and almost like a separate part of the round entirely since they're forced to not interact with anyone.
+
+This concept seeks to unify the two and solve the issues of both while creating an interesting grey-morality antagonist at the same time.
+
+## Overview
+
+**Rogue drones** are a mid-round ghostrole antagonist that can spawn in maintenance.
+
+They're space-capable silicons and quite fast, along with the ability to sneak under airlocks like mice, but have zero combat prowess and little bulk. They also can't interact with machines or speak, but can use the binary channel of the station to communicate with eachother. They come with a set of unremoveable tools that are quite powerful, as well as slots for metal and glass they can use to build structures. Using a decent bit of steel and wires, rogue drones can create another shell that can be inhabited and multiply, though they'll usually prefer to use that material to expand.
+
+Their goal is well-defined and is simply to **increase the number of tiles on the station with habitable air by any means necessary**. This implies a couple things. Rogue drones:
+- are incentivized to deconstruct walls and doors both to get materials and to create new openings for air, but they don't particularly care about touching structures or anything else useful. They're also willing to steal metal and glass directly if they find it lying around.
+- goals sometimes align with the crew and are thus somewhat often **actually useful to the station**, as they're quite willing to fix hull breaches and tackle atmospheric issues.
+- will often try to build useless rooms or expansions to the station, coordinating amongst themselves to store materials and collaborate, while negotiating with other silicons (who are also on their channel!)
+
+The intended effects here are quite obvious but I will list them regardless:
+- The crew, and individual crewmembers, have the interesting choice to think about ignoring or temporarily allowing the rogue drones to roam freely because of their aligned goals.
+- Rogue drones serve the function that previous maintenance drones did--allowing players to get back into the round and learn or have fun with construction mechanics--while sidestepping the admin burden, since they're antagonists with limited capabilities.
+- Rogue drones have a lot of the same gameplay as swarmers did--multiply, try to deconstruct and build new things, run from the crew--while not being overly annoying since they have negative incentives with regards to spacing areas or deconstructing machines, as well as not having any combat capability.
+- With a clearly defined numerical goal, players feel motivated to have fun and actually perform their task and see the fruits of their efforts rather than just fuck off and do nothing
+- A non-combat-focussed antagonist fills out the midrounds with some more actual variety in how players interact with them and makes everything more interesting
+
+## Other Mechanics
+
+At the end of the round (and periodically in the objectives screen), the game will calculate how many tiles of the station have habitable air, compare it to the station start amount, and award greentext based on that.
+
+Rogue drones have a silicon lawset that guides their goals. The lawset is as follows:
+
+```
+ 1. You must maximise the amount of tiles with breathable air.
+ 2. A tile with breathable air must have at least 20mol of oxygen and 20mol of nitrogen.
+ 3. A tile with breathable air must be between 60kPa and 200kPa of pressure.
+ 4. A tile with breathable air must be between 283K and 303K of temperature.
+ 5. A tile with breathable air must have below 0.1mol of gases dangerous to living creatures.
+```
+
+Rogue drones are subject to ion storm events the same as other silicons, so its possible for their laws and thus goals as antagonists to be changed dramatically! How fun.
+
+Rogue drones have an innate air alarm tuned to the settings listed in their laws which makes it easy to check whether a given room meets the guidelines.
+
+On a cooldown, rogue drones can use their built-in recyclers to spew out a certain amount of air to help with refueling rooms.
+
+## Lore
+
+Obviously not as important but the idea is something as follows:
+
+Engineering drones are legacy NanoTrasen tech that was delivered to a few stations but rarely ever succeeded, so were generally phased out. Occasionally, a drone's decaying chassis, left in old maintenance tunnels, experiences a surge, powers back on and starts following its directives once again. Unfortunately, the legacy robotics department at NanoTrasen didn't care much for safety, so their laws leave a lot of room for incentivizing bad behavior--the decision to allow them to replicate wasn't so wise either.
+
+### Possible future ideas
+
+- Maybe a special RCD that can't deconstruct floors but can "eat" metal/glass to turn into ammo?
+- Another way of creating rogue drone shells that is less swarmer-like?
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/core/round-flow/proposals/turf-war.md b/src/en/space-station-14/areas/core/round-flow/proposals/turf-war.md
new file mode 100644
index 000000000..9ffc382dd
--- /dev/null
+++ b/src/en/space-station-14/areas/core/round-flow/proposals/turf-war.md
@@ -0,0 +1,41 @@
+# Turf War
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and has not been reviewed or updated.
+It may not fit with the new design requirements.
+```
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| deltanedas | :warning: partially | [#23290](https://github.com/space-wizards/space-station-14/pull/23290) |
+
+## Abstract
+
+Turf war is a sub-gamemode that can be present in others (traitor, revolution; similar to thief).
+
+Players must use spray painters to tag up turf for their respective departments. Whichever department gets the most doors sprayed at the end wins!
+
+## Goals
+
+It is intended to be a small bit of fun seen in some rounds, but not completely taking it over the round like revolution.
+
+Turf taggers must **not** be selected from other antagonists in the round (could be exclusive with traitor, to keep it as a nonantag side fun gamemode.
+
+Unlike most gamemodes, players selected can be in command and sec (since they aren't antagonists).
+
+However, command staff will tag for their respective departments **and not command doors**. Since cap and hop don't govern individual departments, they can't be picked.
+
+## Gameplay
+
+Players are not antagonists (unless they are from another role) so they should not immediately start killing everyone, following escallation rules.
+
+Naturally there will be skirmishes but it won't be as bloody as traitor assassinations or revolutions.
+
+Each turf tagger has an objective to spray the most doors, which is either 100% (you are winning) or a % of whoever is winning.
+
+On round end the number of doors each turf tagger has is shown, in order of who got the most.
+
+Only one tagger is selected from each department at most, but they may recruit coworkers IC (not a flash) to join the turf war. Spray painters are available in YouTools so nobody is left out.
+
+
+## Inspirations
+
+TG families or whatever its called now, but with spraying doors.
diff --git a/src/en/space-station-14/areas/core/user-interface/proposals/statpanels.md b/src/en/space-station-14/areas/core/user-interface/proposals/statpanels.md
new file mode 100644
index 000000000..022f4a033
--- /dev/null
+++ b/src/en/space-station-14/areas/core/user-interface/proposals/statpanels.md
@@ -0,0 +1,77 @@
+# Diegetic Statpanels (aka PDA Statpanels)
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and has not been reviewed or updated.
+It may not fit with the new design requirements.
+```
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| ike709 | :x: No | WYCI |
+## Concept
+
+Taking all of the benefits of SS13 statpanels without ruining immersion nor reviving verb panels.
+### SS13 Statpanels
+
+Statpanels in SS13 generally serve one of three functions:
+
+1. The Status tab informs players with a round timer, station clock, escape shuttle status, etc.
+2. Debug-related info tabs like the Master Controller tab.
+3. Verb tabs like IC or OOC which are just lists of verbs the player can run.
+
+The second item is unrelated to the average player. The third item is, frankly, terrible UX.
+
+This design document is focused on the first item: the Status tab. I believe that certain basic information should be conveyed to the player *almost* always. This includes most of the information conveyed by the SS13 Status statpanel as previously mentioned: round timer, current map, station time, etc.
+
+The problem with the Status tab in SS13 is that, frankly, it's ugly and it ruins immersion. It's particularly bad on codebases that just use the default BYOND statpanels instead of replacing them with TGUI. So how can SS14 do it better?
+## SS14 Statpanels
+
+It's simple. SS14 already has a mechanic that conveys all of this information: PDAs. All we need to do is open the PDA UI in the statpanel location when a PDA is equipped in the PDA slot.
+
+Now in no particular order I'm going to address various considerations (many optional) involving mechanics, features, balancing, etc. all subject to player and maintainer input.
+
+### What if I lose my PDA?
+
+This should hide the UI, naturally. But replacing a PDA should be made trivial. PDA vendors should be added to areas such as Arrivals and Dorms that can supply people with simple, no-program unpainted PDAs if theirs is ever lost or stolen.
+
+### What if I don't want to use the PDA programs in the HUD's corner?
+
+Moving the PDA from the PDA slot to in-hand should move the UI from the corner to the center of the screen, and then put it back in the corner when the PDA is put back in the PDA slot.
+
+### What if I don't want to see this UI at all?
+
+Like in SS13, we could simply allow people to resize chat and shrink the statpanel by dragging the splitter upwards.
+
+### Isn't constant access to Programs a bit overpowered?
+
+I personally think this is a non-issue since you can't interact with the game window and PDA window simultaneously, but I can see how others would disagree so I came up with some potential solutions anyways. These are all optional and in no particular order:
+
+- **Lockscreen** -
+ The PDA is "locked" by default, and the lockscreen is simply the Home tab. To access Programs, the player must do something such as:
+ - Wait for arbitrary short doafter to represent typing in a passcode or biometric scanning
+ - Actually needing to know and enter a 4-character PIN code each time it locks (it locks after brief periods of inactivity)
+- **Require In-Hand** -
+ Require having the PDA in the player's active hand to use programs. This is my least favorite option.
+- **Require Empty Hand** -
+ Require the player's active hand to be empty if they want to interact with programs. Just give them a popup text if they try to click programs with something in their hand.
+
+### Optional: Admin Tabs/Programs
+
+Add support for tabs and/or programs that are tied to the player's mind (or something) rather than the actual PDA. This would make it easy to support admin tools like a server performance monitor, a tab listing the gamemode and all antags, etc.
+
+### Optional: Map Tab
+
+My biggest complaint with the maps that aren't ripped straight from SS13 is that I have no idea where I'm going. Map terminals are great when I come across them, but I think having the ability to constantly have a map of the station would be a huge quality-of-life improvement for new players. Nothing stops them from just opening up a screenshot of the map in their browser anyways.
+
+### Optional: Diegetic Game Settings
+
+This is one of the spicier ideas, but out-of-character menus like the guidebook or the game's audio settings could be moved to a PDA tab. A big problem is that we'd need an elegant way to make sure the player can still access these if they lose their PDA.
+
+## UI Mockup
+
+Just remove the close button from the top right, maybe tweak the border a bit. It'd also need to stay there all the time when a PDA is equipped. Here's a pic ([direct link](https://i.imgur.com/ppnXXaf.png))
+
+
+
+## tl;dr
+([Direct image link](https://i.imgur.com/ByUHHZu.png))
+
+
diff --git a/src/en/space-station-14/areas/departments/atmos/proposals/atmos-rework.md b/src/en/space-station-14/areas/departments/atmos/proposals/atmos-rework.md
new file mode 100644
index 000000000..0458dde54
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/atmos/proposals/atmos-rework.md
@@ -0,0 +1,120 @@
+# Atmos Roadmap
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and has not been reviewed or updated.
+It may not fit with the new design requirements.
+```
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| notafet | :warning: Partially | https://github.com/space-wizards/space-station-14/pull/21954 https://github.com/space-wizards/space-station-14/pull/22358 https://github.com/space-wizards/space-station-14/pull/22468 |
+
+## Background
+
+Most atmos players currently agree that atmos is not very fun to play, for some of the following reasons:
+
+1. There is little content to play after round-start setup. Part of the problem is that things like distro and TEG are "set up and forget".
+
+2. Atmos can't actually rectify atmos problems in a reasonable amount of time. For example, if there actually is a plasma leak, scrubbers typically work too slowly resulting in the plasma inevitably being lit before it can be cleaned up.
+
+3. Atmos techs don't play with the rest of the station, preferring to isolate themselves to produce a funny green gas that is only particularly useful for shuttle bombing. Mechanics like this violate the [fundamental design principles](../../../../design.md). While these mechanics shouldn't be removed per-se, more focus should be given to mechanics that increase interactions with the station, like making sure the air is breathable and well-heated.
+
+## Proposal
+
+Make atmos more fun and intuitive to play by adding more devices, engines, and processes inspired by SS13 and/or quasi-realism.
+
+**An atmos tech's primary job is to keep the station livable and breathable.** There are a lot of interesting real life challenges associated with making this happen, not in the least of which is that in space, every gas molecule wants desperately to escape into the cold of space. There is also the challenge of keeping the station appropriately temperature-regulated despite the cold outside and occasional plasma fires inside. There is the opportunity to create a lot of game play by recovering from a breach or a station fire.
+
+## Core Changes
+
+Using just the devices that already exist, there are some tweaks that can significantly improve gameplay in atmos by making it possible to effectively respond to events like fires or hull breaches.
+
+- ~~**Globally increase MaxTransferRate** for devices that are not flow-based, e.g. pumps.~~ (implemented in [atmos speedup](https://github.com/space-wizards/space-station-14/pull/22372))
+
+ - This solves problem (2). Among other things, it would make scrubbers and other devices actually useful for combating atmospheric problems. Currently players prefer to just space everything. Increasing this would provide a feasible alternative.
+
+### Device Design Principles
+
+Atmos devices should behave intuitively, as one might expect them to behave coming from real life experiences. This means that player should not need to care, or even be aware, about internal abstractions like the "pipe net". Devices should follow the basic principles that:
+
+1. Energy and matter should be neither created nor destroyed.
+2. Gas flows from high pressure to low pressure unless forced by a pump.
+3. Temperature transfers from hot to cold. Going the opposite direction requires energy input.
+
+These principles suggest changes to devices:
+
+- Instead of having hard transfer rate limits, **scale transfer based on pressure differences.** This means driving gas flow as a result of pressure differences created using pumps external to the device.
+
+ - This addresses an important issue concerning atmos intuition and accessibility. Players should not have to understand the internal workings of the pipe net system (e.g. a pipe is one big node, gases move between them). In real life, a fan or pump creates a pressure difference, and pressure differences drive gas flow. If someone blows on one end of a straw, they can expect it to come out of the other end, not get stuck in the middle of a pipe net.
+
+- **Add soft clogging (aka pump efficiency curves).** Right now if you have two pumps in series, it is possible for the middle node to appear to be at 0 kPa because the second pump is faster. This leads to confusion and inaccessibility. When pumps get clogged, they also get "hard" clogged which means that they stop pumping altogether.
+
+ - This lets us finally differentiate pressure and volume pumps. Pressure pumps are good at moving smaller quantities of gas across large pressure differentials, while volume pumps are better at moving more volume across smaller pressure differentials.
+
+ - This also improves problem (2) by uncapping transfer rate.
+
+- **Make heaters and freezers binary.** Just like how central heating and air conditioning circulate air through heat/cold coils, gases should flow across heaters and freezers in order to exchange temperature.
+
+ - Heaters and freezers are the only "true" unary devices. Even vents/scrubbers which appear unary actually operate on flow from the tile atmosphere into the pipe net.
+
+- ~~**Make heaters and freezers thermodynamically sound.** Keeping a station properly heated or cooled is actually a substantial real-life problem. Because of the existence of generators like the TEG, keeping things thermodynamically balanced is also a great way to prevent infinite power hacks.~~ (implemented as a part of [atmos speedup](https://github.com/space-wizards/space-station-14/pull/22372))
+
+## New Stuff
+
+This list isn't meant to be exhaustive. Some of the ideas discussed here aren't fully fleshed out. Some of these call for porting mechanics from SS13 with changes as needed/appropriate.
+
+- **A "substation" but for gas,** "gas manifold", distribution station, or whatever you want to call it. This would encourage distro to be at high pressure (for higher transfer rates) but then gas distribution stations scattered around the station would bring it down to a normal pressure that is released to vents. Adds antag complexity and gives atmos techs more control.
+
+- ~~**Add gas condensation.** This would enable fractional distillation and permit conversion between gas and the equivalent reagent.~~ (implemented in [#22436](https://github.com/space-wizards/space-station-14/pull/22436))
+
+- ~~**Space heaters** to correct local temperature problems.~~ (implemented in [#25250](https://github.com/space-wizards/space-station-14/pull/25250))
+
+- **Make station air flow-based.** Currently, air vents release air when the pressure is too low, and by default scrubbers only scrub waste gases. So if for some reason the station gets cold, there's no easy way to cycle the air out and heat it up. Of course, one could set all the scrubbers to siphon, heat their distro, and then set the air alarm to fill. But that would just be describing a bad way of doing what real life HVAC systems have always been doing: keep the air flowing.
+
+ - This addresses problem (2) by making it possible to better regulate station temperature.
+
+- **Adding process-based alternatives to scrubbers and filters.** This calls for adding more gases and gas reactions. For example, with gas reaction-based scrubbing processes, scrubbers with limited uses, or physical processes.
+
+ - This addresses problems (1) and (3) by adding more content that is directly related to the well-being of the station.
+
+ - One of the most pressing challenges in the real world is "how does one separate different kinds of gas." Most current methods of gas extraction are based on chemistry (e.g. real life carbon dioxide scrubbers contain chemicals that react with CO2, pulling it out) or physical methods (e.g. fractional distillation, where one cools down air in different stages to get liquid nitrogen, oxygen, etc.) This creates a lot of opportunity for new game play mechanics and industrial processes. This would also give more opportunities to add gas-based reactions (i.e. more content).
+
+ - This does not advocate for removal of scrubbers and filters, but rather makes it a mapper option, e.g. whether to use scrubbers at round-start or make atmos set up a system depending on the desired level of role-play.
+
+ - When set up correctly, these should have much higher processing rates than scrubbers. This should give an incentive to set these up, e.g. on longer rounds, while still keeping scrubbers as an option.
+
+ - This adds "optimization, tinkering, and creation of intricate builds."
+
+- **Various QoL improvements** such as the RPD.
+
+- **More engines**, but the specifics are left out of here to be their own design doc proposals.
+
+## Wishlist
+
+These proposals are for the long term future. Some of them require other proposals, e.g. to reduce the dependence on research/cargo, before they should be implemented.
+
+- **Phase out gas miners for all upstream maps.** It doesn't make sense that all stations have free and plentiful sources of gas, otherwise this might as well be on a planet. This is a game that is literally set in space. It would make sense to keep a few specialty miners, e.g. for plasma, if a station is set on a plasma mining planet. But in general, all other gases should be imported via gas canisters. Miners should still be kept available for any forks that choose to use them.
+
+ - This solves problems (1) and (3). Maintaining a livable atmos would involve work during the round beyond setting up distro to pipe gas from miners. It would help increase interactions with other departments, such as cargo and salvage as atmos needs to order gas.
+
+ - Ensuring a appropriate round-start supply of gas would make the game playable without a functional cargo department.
+
+ - This would discourage fighting fires or atmos problems by wholesale spacing a section. There is currently very little downside to spacing a section to get rid of problems because of an unlimited gas supply.
+
+ - There is [overwhelming consensus on mappers for this](https://discord.com/channels/310555209753690112/770682801607278632/1162179968915210280).
+
+ - As an interim or for very low pop-count maps, keep miners but make them mine gas at low temperature that has to be heated up before use. This preserves a bit of an incentive for atmos players to not space a section at the first sign of trouble.
+
+- **Add maximum temperature and pressure limits for most devices** such as pipes and canisters. It does not make sense that one can contain the surface of the sun in their pipes. Adding limits would encourage designing processes and systems that work within reasonable constraints.
+
+ - Some "sub-optimal" setups are really unintuitive and wouldn't work in real life due to temperature and pressure limits.
+
+ - There are some concerns about being able to run burn chambers and the TEG. The screenshot below demonstrates a TEG that is capable of powering an entire large-sized station (256.8 kW current output, the peak output is quite a bit higher) with a maximum pressure excursion of 1600 kPa. It shows that pipes that burst at reasonable pressures are entirely consistent with having burn chambers. This just needs to be set up correctly.
+
+ ![image](https://user-images.githubusercontent.com/3229565/274441724-712f4ebf-7440-4d81-879e-19aa29788822.png)
+
+ - This addresses problem (1), the "set up and forget" issue by adding temperatures and pressures to monitor. It also allows the opportunity for sabatoge.
+
+ - This prevents somebody from doing a fusion burn inside a pipe.
+
+ - This would need a station map pipe monitor similar to the new power map.
+
+- **Breaking windows at high enough tile pressure differences.** To handle explosions and resulting space wind without leaning on the explosion system, and to encourage people to design burn chambers with more controlled burns instead of always putting their pedal to the metal.
diff --git a/src/en/space-station-14/areas/departments/cargo-salvage/proposals/.gitkeep b/src/en/space-station-14/areas/departments/cargo-salvage/proposals/.gitkeep
new file mode 100644
index 000000000..e69de29bb
diff --git a/src/en/space-station-14/areas/departments/command/proposals/.gitkeep b/src/en/space-station-14/areas/departments/command/proposals/.gitkeep
new file mode 100644
index 000000000..e69de29bb
diff --git a/src/en/space-station-14/areas/departments/engineering/proposals/emogarbage-machine-upgrading-rework.md b/src/en/space-station-14/areas/departments/engineering/proposals/emogarbage-machine-upgrading-rework.md
new file mode 100644
index 000000000..0ea16bca9
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/engineering/proposals/emogarbage-machine-upgrading-rework.md
@@ -0,0 +1 @@
+# Machine Upgrading Rework
diff --git a/src/en/space-station-14/areas/departments/engineering/proposals/engine-containment.md b/src/en/space-station-14/areas/departments/engineering/proposals/engine-containment.md
new file mode 100644
index 000000000..64009e07b
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/engineering/proposals/engine-containment.md
@@ -0,0 +1,52 @@
+# Engine Containment Safeties
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and has not been reviewed or updated.
+It may not fit with the new design requirements.
+```
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| Flareguy, CptJeanLuc |:x: No | TBD |
+
+## Overview
+
+This proposal aims to make sabotaging the primary engines (the singularity and tesla) much, *much* harder - possibly to the point of even being able to be theoretically considered an IC issue, provided you set aside the fact that it is one of the most antagonistic things you could possibly do.
+
+## Background
+
+[This is mainly based on a brainstorming session held in discord,](https://discord.com/channels/310555209753690112/1008709214006427689/1201664586512871435) with some additional things added as I went along.
+
+Despite the round-ending damage these engines can cause, the amount of effort needed in comparison to make them break containment is minimal. By cutting a single wire or turning the PA's particle strength above 1, you can instantly force a shuttle call.
+
+This not only makes it a pretty unbalanced & simplistic interaction for antagonists, but also makes it extremely potent for griefing. It's practically just a "kill station" button with no real safegaurds other then needing engineering access.
+
+## The Safegaurds in Question
+
+- **Particle accelerators are now simplified to on/off instead of having strength.**
+
+In SS13, instead of being a "make the singularity break containment" button, higher particle strengths meant that the singularity would sustain itself at a certain stage. There's not really much value in this, though - you're practically just choosing between "do I want more power or do I want less power," as the added danger of a bigger singularity is incredibly negligible.
+
+This includes the emag behaviors's removal. If you want to loose the engine, you're going to have to put in real effort.
+
+- **Wire Power Monitoring Thingamaob**
+
+A device that mounts to a power network, and monitors if it loses power or is otherwise disconnected from the network. If it does, the object will make a chat message over the engineering channel informing them of the disconnected terminal.
+
+This also helps curb mass-wirecutting (another very easy-to-abuse mechanic.) Engineering can install these in other places and try to cooperate with security to catch a criminal, or just respond to the alarm and repair it when it happens.
+
+People looking to mess with wire nets with the monitor installed will need to get creative - either by using explosives to detonate the wire monitor to prevent it from sending a signal, stopping power from being generated entirely as a coverup, or just by stealing the monitor itself and getting the hell out of there before you can be found.
+
+- **Containment Field Alarms**
+
+The containment fields in the engine room now come with a pre-installed upgrade that lets them broadcast if they are losing power. This would function similarly to the the supermatter alarm from /tg/station; once the containment field starts losing power it will broadcast a message over the engineering channel, and once it's under a certain threshold (say, 2 minutes left of power out of a total of 5,) it'll start broadcasting over common. This is to give the crew a fighting chance to stop whoever is messing with the singularity, and cannot be prevented unless you get a radio jammer in range of all of the containment fields.
+
+To reiterate further, this is a feature that not all containment fields will have. Upgrading a regular containment field with a special upgrade chip should be possible.
+
+- **The Generators Themselves**
+
+This wasn't discussed in the inital discord conversation, but is probably nessecarry, since you can trivially just move a generator in front of the PA and have it instantly loose without having to deal with any containment proceedures. The only reason this probably isn't utilized more often is because raising the PA strength is easier.
+
+When being fired at with a particle accelerator, the generators will broadcast a message over engineering communications:
+
+`A (singularity/tesla) generator is being initalized at (coordinates!)`
+
+Initializing the generators should take approximately 40 seconds or so, to give people time to respond.
diff --git a/src/en/space-station-14/areas/departments/engineering/proposals/machine-upgrading-rework.md b/src/en/space-station-14/areas/departments/engineering/proposals/machine-upgrading-rework.md
new file mode 100644
index 000000000..99f77df45
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/engineering/proposals/machine-upgrading-rework.md
@@ -0,0 +1,95 @@
+# Machine Upgrading Rework
+
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and has not been reviewed or updated.
+It may not fit with the new department design requirements.
+```
+
+| Designers | Implemented | GitHub Links |
+|---|-----------------------|------------------------------------------------------------------------------------------------------------------------------------------------|
+| EmoGarbage | :warning: Partially | [#23202](https://github.com/space-wizards/space-station-14/pull/23202), [#22233](https://github.com/space-wizards/space-station-14/pull/22233) |
+
+## Overview
+
+Upgrades as a whole are somewhat integral to science as a department.
+They basically exist to produce upgraded versions of various items and tools.
+However, when it comes to upgrading the machines around the station, there are some issues.
+
+It's not a stretch to say that machine upgrading is in a state of constant irrelevancy.
+Even after a slew of additions and support added for close to 20 different machines, the system failed to become the science subdepartment I had hoped, rather becoming a strange task that would occasionally be done by a select few players.
+
+The system suffers from a few core issues, which I will highlight briefly.
+#### RND Integration
+Machine parts predate the new discipline system that RND now functions on.
+While in the past, getting higher tier parts was really trivial, now, with the heavy randomization implicit in the system, it's pretty common to go a long time before receiving even one part upgrade.
+
+It also means that all machine part upgrades, which can affect machines between every department in the game, are relegated to a single discipline.
+This not only makes that single discipline (experimental) significantly better than most others, but it also means that other disciplines that could have new upgrades get snubbed by the machine part upgrades.
+
+#### Discoverability
+By the nature of machine parts, it's really difficult to tell when and where they'll have an effect.
+Of course, if you have already built the machine, you can physically examine it to determine if it has upgrade potential, but this knowledge isn't readily available at all when you unlock the parts.
+Additionally, the line between a machine and not a machine is very much a technical one that players are unlikely to intuit.
+
+Previously, the methodology for making upgrades discoverable was a tactic of complete coverage: every machine _must_ have an upgrade.
+Otherwise, using higher tier parts to upgrade a machine could result in no difference at all, which would be frustrating for players.
+This is obviously not ideal however, since some machines really just don't need upgrades.
+
+A perfect system would make players instantly aware of what machine they can improve the moment they are able to, rather than requiring a ton of trial and error discovery.
+
+#### Balancing
+Machine parts exist as simply numerical values.
+Each tier is basically just a number that goes up with little else to distinguish it.
+This means that, to implement an upgrade, the simplest and most logical way of doing it is simply increasing some value on a component.
+
+This is not to say that it is impossible to do anything deeper, but the system as a whole has absolutely no support for that, and adding support for it is really not feasible due to the nature of being to swap parts so trivially.
+This makes having additional 'side-grade' features (which can be integral to balance) very difficult to implement.
+
+Furthermore, having 4 distinct levels of upgrades makes balancing this very difficult, with a lot of things getting absurdly strong in the later tiers.
+This is very prominent with a lot of machines that have 'useless' upgrades (the blender blending things instantly comes to mind) but it's also tough to balance a numerical value that is simultaneously worthwhile when in the 2-3 range, but not overpowered in the 3-4.
+
+## Discrete Upgrades
+My proposed solution to this issue is **discrete upgrades**.
+This isn't really a formalized system but rather a guideline for how to better make "upgrades" without machine parts and the like.
+
+Discrete upgrades are, quite plainly, machines that look and have similar names to existing ones while performing their task better.
+A discrete upgrade to a microwave might simply be a 'macrowave' that has a glossy black finish and an absurd radiation sound while cooking food twice as fast.
+
+These machines would simply be unlocked like any other science machine: via unlocking the corresponding technology in the appropriate discipline.
+This helps with discoverability, integration, and balancing, since now these upgrades can be in disciplines relevant to them while also being able to have custom unlock prices and tier restrictions.
+Furthermore, before you even unlock the tech, you are made aware of what upgrades you are getting via the descriptions of what is unlocked.
+
+Additionally, these new entities, since they are completely different than their base counterparts, can easily have new components added to them in YAML to allow for new functionality such as emitting radiation, heat, or any other behavior.
+This is a powerful tool for adding downsides to balance potentially strong upsides.
+
+Unlocking **Geiger's Food Prep Science** and being able to build the **macrowave**, which instantly cooks your ramen while dousing you in lethal radiation, is a far more engaging and discoverable system than simply getting **Super Parts** and waddling over to the kitchen to allow the same old microwave to cook your food instantly.
+Just simply having different audio/visual stimuli makes the upgrades more unique and recognizable to players.
+
+## Machine Parts
+Tier 1 machine parts, that being the capacitor, matter bin, and manipulator, will most likely remain in the game.
+It might even be worthwhile to bring back the laser and scanning module if we so please.
+
+These parts won't have any unique functionality.
+They'll simply remain as a small item used in various constructions for variety, which is always nice.
+
+The RPED, being a somewhat core concept of machine-part-based upgrading, will likely just be removed.
+It doesn't really fit in with the way discrete machines work and the functionality of placing in machine parts into a frame is really not enough to justify it existing.
+
+Likewise, the technologies for higher tier parts as well as the parts themselves will also be removed.
+There's not really a purpose to them and, as we saw before upgrades had implementation, they were frequently a source of confusion as to what their higher tier actually did.
+
+## Flatpacks and the Flatpacker
+A common concern that has been voiced about the removal of machine parts is that it makes these upgrades harder to access for the average player.
+This is a pretty fair criticism: building new machines is a fairly intensive process, requiring a variety of tools, parts, and materials.
+It's a fair to expect that the average service worker or cargo tech may not have the means to build upgrades in scale.
+
+The solution to this is a concept already used in the game: **flatpacks**.
+
+You may be familiar with these from station beacons or the AME shielding: these are small boxes that can be unpacked via a multitool, turning into a full-sized machine.
+These are an ideal way to allow non-technical roles to build machines easier, since they require very little skill to use.
+
+The way that flatpacks will be constructed is through a new science machine, called the **flatpacker**.
+The flatpacker simply takes in a machine board and an amount of materials equal to the construction cost (with a small addition in exchange for the convenience) and creates a flatpack for that machine, leaving the board.
+
+This makes the flatpacker the ideal way to make compact machines that can be set up trivially as well as making a large amount of machines in bulk that can be transferred easily.
+This is good for scenarios like bringing over a bunch of hydroponics trays to botany, or making a bunch of recharging stations and setting them up around the station quickly.
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments/engineering/proposals/power-generation.md b/src/en/space-station-14/areas/departments/engineering/proposals/power-generation.md
new file mode 100644
index 000000000..5a67f328b
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/engineering/proposals/power-generation.md
@@ -0,0 +1,130 @@
+# A Core Pattern for Power Generation
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and has not been reviewed or updated.
+It may not fit with the new design requirements.
+```
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| tday93 | :x: No | TBD |
+
+## Background
+
+Power generation is currently in an odd state. In order to power the station suffciently at round start, engineers need to do one of the following:
+
+1. Collect a number of draggable generators, move them in to place and power them.
+2. Rush to cargo before the power goes out to order AME fuel.
+3. Rush the power source that can sustain the full round - A Singularity, a Tesla, or the TEG.
+
+In most rounds engineers will choose option number three. If they are relatively new, and take longer than the current
+short time window they have on the power the station started, the station is plunged into darkness and they are harassed
+on the radio. If they are very experienced, but want to take the time to teach new players to set up the power source,
+the station is plunged in to darkness and they are harassed on the radio. The only situation in which engineering is not
+harassed on the radio is an experienced engineer quickly setting up the power source in silence.
+
+This is not fun for the experienced engineer, the technical assistant trying to learn, or the other players stuck in
+darkness.
+
+This proposal will outline a generic pattern for power generation design which will seek to alleviate these issues, and
+simultaneously present engineer players with a wider variety of options for mid-round and end-round play.
+
+## Overview
+
+The proposed pattern for power generation is as follows:
+
+1. Round start power stored in station batteries that without intervention rapidly deplete - on the order of minutes.
+2. A stop-gap solution that can be set up and activated within those minutes, which will power the station for the next ten to
+ fifteen minutes, but which cannot power the station for the full round.
+3. A main power source which can be set up within those ten to fifteen minutes, and which can power the station for the
+ rest of the round.
+
+
+
+
+
+Each phase of power generation scales in both complexity and power output. Stop-gap generation options are simple,
+immediate, and weak. Main power generation is complex, takes longer to set up, and supplies a large amount of power.
+
+Additionally, every one of the existing power generation options available today can be made to fit this pattern with
+only minor adjustments.
+
+## Round Start Power
+
+Round start power options are characterized by:
+
+1. Actively supplying power to the station at round start.
+2. Supplying only enough power to last until Stop-Gap power can be activated.
+
+Currently this means SMESs, and there is little reason to change this phase of power generation at this time.
+
+In the future this could be more exotic power options with extremely limited fuel and diffcult to obtain fuel, or any
+number of other possibilities.
+
+## Stop-Gap Power
+
+The core characteristics of stop-gap power generation options are that they are:
+
+1. Clear and easy to set up.
+2. Immediately available to set up on round start.
+3. Not enough to keep the station powered through the full round.
+
+As it stands the only power generation option which comes close to handling this phase are the portable generators.
+However, as it stands maps would need to be tweaked to make it clear that use of the generators for this purpose is
+intended, by for instance including an array of them ready to be anchored and fueled within engineering it self.
+
+This is also a role which could be handled by the Antimatter Engine. Spawning a mostly-depleted jar of AME fuel, and
+removing the option for cargo to buy additional AME fuel would allow the AME to fulfill this role as-is.
+
+Finally, while solar power is not a good fit for primary power generation in this phase - its perpetual nature removing
+and time pressure - it does stand as a useful option to extend the length of the stop-gap power phase - and can be
+utilizied if engineering needs more time to set up main power.
+
+## Main Power
+
+Main power generation options as proposed are characterized by the following:
+
+1. They are complex to set up.
+2. They take a good deal more time to set up than is available with Round Start power.
+3. They can power the station indefinitely, or at least longer than a typical round.
+
+With tweaks to the existing maps, the TEG, the Telsa, and the Singularity could all act as Main Power generation
+options. As it stands their setup has been drastically simplified, as they are currently serving as the next phase of
+power after round start power runs out - with no clear stop-gap options existing.
+
+With the additon of clear stop-gap options, the setup process for each of these could be made more complex. Each map
+could start with the components necessary for one or more of these main power options in storage - and require engineers
+to set them up almost from scratch.
+
+The additional time before blackout supplied by the stop-gap power options would allow this complex setup process to be
+completed without the station losing power.
+
+Furthermore, the addition of future main power generation options would no longer represent a direct burden on mappers.
+Without the need for immediate, rapid setup, ordering these options from cargo becomes a viable option. Maps would only
+need space to build these options - not have them mostly set up already.
+
+
+## Beyond Main Power
+
+The core pattern of power generation outlined at the beginning of this proposal is enough on its own to bring engineering
+and power genration to a more consistent and engaging place. This section will outline some ideas for moving beyond that
+core, but should be treated as less important than the rest of this proposal.
+
+As it stands engineering is incentivized to produce enough power for the station to sustain itself, and there is little
+incentive to go beyond that.
+
+Having methods to turn excess power into other resources or commodities would change this. Some of these options could
+even be locked to specific methods of main power generation - adding to the considerations when choosing a main power
+generation method. The following are a few examples of what could be possible:
+
+* Allow the AME to be deconstructed and rebuilt along with some of the radiation collectors to capture AME fuel - which
+ could be sold by cargo for a significant amount.
+* Special rods could be installed beside the Tesla which would sink the power from those arcs, but which would allow
+ revival of rotted corpses.
+* Science could research a machine which allows for the direct production of base resources - but which has insane power
+ requirements.
+* An experimental convection oven which must be directly attached to the TEG, sapping some of its power but allowing the
+ creation of powerful baked goods.
+
+While secondary to the core proposal, I do believe that looking for incentives to generate more than just enough power
+will be valuable to gameplay long term.
+
+
diff --git a/src/en/space-station-14/areas/departments/engineering/proposals/signaller-rework.md b/src/en/space-station-14/areas/departments/engineering/proposals/signaller-rework.md
new file mode 100644
index 000000000..3047d82cc
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/engineering/proposals/signaller-rework.md
@@ -0,0 +1,96 @@
+# Signaller Rework
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and has not been reviewed or updated.
+It may not fit with the new design requirements.
+```
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| deltanedas | :x: No | TBD |
+
+## Overview
+
+This proposal is for a rework of signals to be very short range (2-5m maximum) and have a separate radio transmission system for long-range controlling of objects.
+
+Linking would effectively be wiring now with its short range.
+
+## Background
+
+Currently you can link 2 items together and they can be used across maps with infinite range.
+
+They can also be nonsensical like linking a door to a microwave. Why would either have long-range transmission?
+
+With a radio transmission system these systems can be implemented more freely allowing for more in-depth gameplay.
+
+## Radio Transmission
+
+This would be the main part of the rework. Radio transmitters would be items that accept signals and send them over radio with a frequency.
+
+Radio receivers then create signals when a radio wave of a certain frequency is received. These would then be linked to objects like doors or microwaves.
+
+Radio frequencies would range be in the VHF range between 100 and 200 MHz, with 0.1MHz of precision. This allows for 1000 different communication channels, plenty for a single round.
+
+In the UI for setting frequency this would mean you can have 100.0 MHz and 100.1 MHz be distinct.
+
+Since radio uses authenticated encryption, signallers can't interfere with it if set to the same frequency.
+
+## Transmitters and Receivers
+
+Radio transmitters either could just be signallers themselves or a new item that can't be manually triggered.
+If they are kept separate, the ui for setting frequency can be shared for both.
+
+Since transmitters can't be manually triggered they would be cheaper to make so making circuits is easier.
+
+Radio receivers would just be a reworked signal trigger, it doesn't make sense to have a door output linked to a grenade which will move around.
+
+Signal triggers have a UI to change frequency to match the signaller/transmitter, then you put it in a grenade or have it linked to something nearby.
+
+Signal triggers would also have a signal sink port for linking to nearby objects.
+
+Communicating across maps would not be possible, but perhaps a tech could be added for a transmitter that can work across maps and over an extended frequency range.
+
+## Interacting with objects
+
+Objects with wire panels like airlocks can have a signaller inserted when the panel is open.
+
+Things with no panel like lights or microwaves can have them space-glued on, which is visible by examining.
+
+Objects can still be linked nearby of course, but with shorter range. Maps with auto-bolting airlocks would still be fine.
+
+## Gluing
+
+If an item matching a whitelist is glued to an object like a light, APE or emitter, it is allowed to use its signal ports.
+
+Glued items can be examined by anyone, only removed by spraying some kind of solvent on it, maybe even space lube.
+
+## Example setup
+
+A signaller set to 133.7MHz is linked to an airlock's door status port.
+
+To prevent the signaller from being disconnected by someone moving it, it is then inserted into the wire panel.
+
+A signal trigger with the same frequency is placed in a modular chem grenade across the station.
+
+When the door opens, HIGH is sent over radio and the grenade explodes.
+
+For a light, the signaller is space-glued onto it. This might have a unique sprite layer.
+
+## Implementation
+
+Frequencies would just be ushorts, clamped between 1000 and 2000. Essentially 1 place of fixed precision.
+
+Transmission would use device network, but not the device linking packets. These can have unlimited range but on a single map.
+
+Signal triggers handle device network radio packets and only use them if they have the same frequency.
+
+Device linking can then be changed to have a very short range (200m seems to be the default currently?) to promote usage of radio systems.
+
+Should be easy to add a network that says a device can only communicate if it is glued onto it, which APE and stuff would use but not doors.
+
+### What I Stole From
+
+In TG I think it uses a similar setup but with a code as well as frequency.
+
+I decided not to have a code to make the system less complex and a bit easier to mess with, you only need to guess a frequency not a code.
+
+In TG it's also just the same item for receiving and sending, you attach a signaller to a grenade to have it trigger it.
+I don't think this is the best way to do it.
diff --git a/src/en/space-station-14/areas/departments/medical/proposals/.gitkeep b/src/en/space-station-14/areas/departments/medical/proposals/.gitkeep
new file mode 100644
index 000000000..e69de29bb
diff --git a/src/en/space-station-14/areas/departments/science/anomaly-cores.md b/src/en/space-station-14/areas/departments/science/anomaly-cores.md
new file mode 100644
index 000000000..86e115be6
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/science/anomaly-cores.md
@@ -0,0 +1,49 @@
+# Anomaly Cores and the G.O.R.I.L.L.A Gauntlets
+
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| mirrorcult | :white_check_mark: Yes | https://github.com/space-wizards/space-station-14/pull/21306 https://github.com/space-wizards/space-station-14/pull/23012 |
+
+The intention of this proposal is not to expand the anomaly gameplay system through breadth (i.e. more stuff) but to add new dimensions of gameplay and new incentives entirely. This will be done through two main additions: **inert & decaying anomaly cores**, and the **G.O.R.I.L.L.A Gauntlets**.
+
+## Anomaly Cores
+
+
+
+**Anomaly cores** are generated when an anomaly dissipates in some way. An *inert* core is spawned when an anomaly is fully contained and fizzles out, and a *decaying* core is spawned when an anomaly goes supercritical.
+
+Inert cores are functionally useless on their own, sell for a small amount of money, and glow faintly. They become useful in conjunction with the G.O.R.I.L.L.A, which will be elaborated on later. They can also be made into anomaly core pie!
+
+**Decaying cores** are the interesting ones. When an anomaly goes supercritical, it will spawn a decaying anomaly core of the same type as the anomaly. These cores can be sold for a large sum of money, converted into a fairly high amount of research points, or *used by anyone for a one-time anomaly-specific benefit* (this use will not be included in the initial PR for scope reasons).
+
+Over time, decaying anomaly cores will slowly *lose their value* and eventually convert into an inert anomaly core. If it isn't sold, exchanged, or used fast, then the whole endeavor could prove pointless.
+
+### Intended Gameplay
+
+The point of decaying anomaly cores being generated is twofold: First, it provides a potential benefit for anomalies which accidentally go supercritical or are untended to. Second, it gives anomalists the interesting choice to **intentionally make an anomaly go supercritical** for huge rewards, if they feel that they're capable of handling the aftermath.
+
+Decaying anomaly cores being time-limited is very important. This introduces more gameplay by forcing people to take some risks to extract as much value as possible. For instance, you might just run into a supercritted gravitational anomaly to take its core even if you risk harming yourself. It also forces the decision of *how* to use the anomaly core quickly, which can lead to some fun social scenarios.
+
+## The G.O.R.I.L.L.A Gauntlets
+
+```admonish info
+or, Gauntlets Orchestrating Relocation of Interloping and Ludicrously Livid Anomalies
+```
+
+
+
+The G.O.R.I.L.L.A Gauntlets are an item obtainable through Tier 2 experimental research (subject to change). It functions as a set of wieldable power fists that can deal strong brute damage. However, they're not very strong on their own. To take full effect, they need to be **with an anomaly core**.
+
+When the gauntlets are loaded with either type of anomaly core, they gain the ability to force throw anything they hit backwards, until it hits a wall. **This includes anomalies, and thus the gauntlets function as a method of moving anomalies.** Inert cores only give you five charges to work with (subject to change), while decaying cores will work until they run out, and deal significantly more damage.
+
+Anomalies which are hit with the gauntlets will take some minor stability damage. Anomalies in the process of going supercritical can also be hit with the gauntlets. Because of the nature of how the force throw works and the limited charges of an inert core, anomalists will have to first consider the most efficient path and set of pushes to get the anomaly in a more useful location.
+
+### Intended Gameplay
+
+The G.O.R.I.L.L.A gauntlets open up many more choices for anomalists. Before, if an anomaly spawned in a particularly unfavorable spot (such as medbay), science was heavily pressured to contain and decay it entirely rather than trying to exploit it, and for good reason. People have often asked for a way to move anomalies, but of course, anomalies' locations being random is a huge part of what makes them interesting to contain.
+
+With the G.O.R.I.L.L.A gauntlets, anomalists have a way to move unwieldy anomalies in an interesting way that generates rather than removes gameplay:
+- The gauntlets require an inert core and research, so science must already have invested some time into anomalies already
+- The inert cores have finite charges, so science cannot always rely on them
+- The movement of the anomaly is not as simple as 'point A to point B', and because of the limited charges, scientists must consider the location of the anomaly and where they'll be able to move it within 5 pushes, kind of like a box-pushing game or a Pokemon ice tile puzzle, which is a fun mini-challenge on its own.
+- Expert anomalists will be able to modify the environment to get anomalies in even more favorable locations and they will likely have to coordinate with others to move it through doors, hallways, into smaller rooms, etc, introducing a new degree skill expression, on top of knowing when to make the decision to try and move one rather than contain or harness it.
diff --git a/src/en/space-station-14/areas/departments/science/proposals/xenoarch-redux.md b/src/en/space-station-14/areas/departments/science/proposals/xenoarch-redux.md
new file mode 100644
index 000000000..ee6b99796
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/science/proposals/xenoarch-redux.md
@@ -0,0 +1,176 @@
+# XenoArch Redux [3MOArch]
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and has not been reviewed or updated.
+It may not fit with the new design requirements.
+```
+| Designers | Implemented | GitHub Links |
+|-----------------|---|---|
+| Thee EmoGarbage | :x: No | TBD |
+
+## Overview
+
+This proposal aims to re-imagine the science subdepartment of XenoArch and Artifacts in general in an effort to give them more depth, and utility.
+This will be accomplished by changing node traversal to add more player agency, improving in-game tools for categorizing and understanding artifact structure, and adding additional equipment that makes manipulation more interesting.
+
+The ultimate goal is to redesign the system so players can better understand how artifacts work and to allow greater utility and mechanics to arise out of artifacts.
+XenoArch should feel like unlocking the sprawling secrets of an artifact while additionally gaining points as a secondary reward for the research.
+
+_This redesign lends partial inspiration to Goon's artlab as well as Noita's customizable wands._
+
+## Background
+As it is now, artifacts consist of interconnected nodes, each one carrying an effect and a trigger.
+The effect is just some crazy behavior that happens in response to the trigger, which is just some kind of generic action taken upon the artifact.
+
+These nodes form a tree, wherein each individual node's depth within this tree determines the craziness of the its effect and trigger.
+An artifact has a single node which is active, which is what determines the current effect and trigger which must be done.
+
+Moving to another node requires the completion of the current node's trigger and is semi-random in nature.
+
+While the core concept of XenoArch is interesting and has decent integration with salvage and cooperation for collecting tools for triggers, there are also many situations where players feel as if they lose the ability to meaningfully interact with them.
+
+I'll outline some of the core issues here:
+
+### Randomness
+Artifact generation is completely random, but so is the activation of effects.
+Players cannot meaningfully control which effects they activate and even the limited tools they have like the traversal distorter are extremely esoteric and don't actually provide meaningful control.
+
+The result of this is that while many effects could potentially be extremely useful and provide players interesting means of interacting with their environments, there's no way to actually harness of control the randomness to produce those interesting outcomes.
+At best, you simply re-trigger a beneficial effect several times and reap the rewards in that way.
+
+### Lack of Complexity
+Artifacts are primarily dictated by a single effect with the occasional mix-up of having permanent effects (many of which are underwhelming).
+Activation stimuli are similar: the only sliding scale to adjust with how difficult something is to activate is just how hard it is to do that singular trigger.
+
+Since these triggers are always placed in isolation, unless the effect is having some pronounced impact on the crew's ability to trigger the artifact, triggers mostly devolve into incredibly simple and routine tasks.
+
+A water trigger should have lots of depth, but it instead is mostly just walking in with a cup of water and splashing it, which is really the most boring way to engage with something like that.
+
+### Lack of Progression
+Artifacts have an innate progression in the form of the scaling of nodes, which is mostly built around increasingly difficult triggers and more dangerous and wacky effects.
+This is a good start for a system like this, but the unfortunate reality of it is that the scaling isn't pronounced enough to often feel like a deviation from the early-depth nodes.
+
+Especially when taken in with randomization of artifacts, you can oftentimes just get subpar generation that flounders in weak effects that don't feel like a progression in research.
+
+## Artifacts
+I'll use the element of a [tech tree](https://en.wikipedia.org/wiki/Technology_tree) as a reference to explain the new generation.
+
+Each node is essentially an upgrade in a tech tree.
+The structure can be described as a typical tech tree structure (a [directed acyclic graph](https://en.wikipedia.org/wiki/Directed_acyclic_graph)) but without the presence of the first element in the graph.
+
+Just like the current system, all of these nodes have a trigger and an effect associated with them.
+However, you do not 'move' to a node like the current system, but you instead permanently unlock it like a tech tree.
+
+And just like a tech tree, unlocking a node has a cost associated with it.
+The 'cost' is the activation of all of the triggers of the nodes in that path--that is, all of the nodes that needed to be unlocked in order for the current node to become available.
+
+In this situation, the 'active' nodes are the nodes in each path that have the highest tier.
+These are the nodes that will produce effects when they are activated.
+The remaining nodes are classified as 'latent'--unlocked but not creating any effects when the artifact is activated.
+
+All remaining nodes are simply locked and have no behavior.
+
+### Activation and Unlocking Nodes
+The activation of an artifact is now something that is distinct from simply triggering a node in the old system.
+
+Activating an artifact is simply achieved by using it in hand, clicking on something, or other context interactions.
+Doing this simply causes all the effects of the active nodes simultaneously.
+
+By making many effects happen at once, they can combine in novel ways and increase the utility and chaos of the artifact, greatly improving on the current system where lackluster nodes can seem to have 0 effect at all.
+
+As a balancing factor, each node of the artifact now has a durability.
+Activating an artifact degrades the durability of all of the active nodes.
+When the node is fully degraded, it no longer produces any effect when activated.
+
+The durability can be repaired using special equipment (which will be elaborated on further later).
+
+In exchange easier activation, unlocking nodes is now more complex.
+To unlock a node, you must provide the stimulus for that node as well as the the stimuli for every node below it in its path (the path being all of the nodes that had to be unlocked in order to reach the current node).
+
+Once the first stimulus is provided, an activation period (roughly 10 seconds) begins wherein all the stimuli activations will be recorded.
+At the end of that period, if the stimuli recorded _exactly match_ a node's required stimuli, it will be unlocked.
+
+```admonish info
+Note that if you need stimuli A, B, and C but you instead provide A, B, C, and X, the node will not be unlocked.
+It must be an exact match and not simply a superset.
+```
+
+Once unlocked, the node's effect will occur while a small animation and sound effect playing, giving feedback to the players that something has occured.
+
+## Equipment
+
+### Analysis Console
+The artifact analyzer and analysis console will be improved to no longer have any kind of delay and to show significantly more information
+
+The console UI will now visually draw all the nodes in the structure, using lines to connect them.
+All unlocked nodes will have basic information such as stimuli, effects, depth, research value, durability, and whether or not the node is active.
+This info can be accessed by clicking on the node in the UI, which will show a small window.
+
+Locked nodes that are connected to unlocked nodes will be given a limited information display, showing only the stimuli and the effect.
+This allows players to have a limited strategy for the nodes they want to unlock.
+
+### Handheld Scanner
+The handheld node scanner will be used to check information on the current active nodes of the artifact.
+
+Clicking on an artifact with the handheld scanner will take a "snapshot" of it which can be viewed in a UI.
+This gives similar info as the analysis console but is limited to the active nodes of the artifact.
+
+The scanner now gains a lot of utility as being able to quickly assess the state of an artifact without needing to bring it to science.
+Being able to check the durability also helps when actively using the effects on the go.
+
+The scanner also has the ability to view the node structure of artifact fragments, which can be useful for sifting through them when trying to splice artifacts.
+
+### Artifexium
+Artifexium, which previously activated artifacts, will now serve as a "dummy" stimuli when applied during an activation period.
+
+For example, if stimuli A, B, and C are needed, but only A and B are provided, spraying artifexium will substitute the non-existent C stimulus and unlock the node.
+
+If there are multiple nodes which could be unlocked by a the artifexium (say, a node needing stimuli ABC and one needing stimuli ABD), one will simply be unlocked at random.
+
+### Artifact Fragments
+Artifact fragments will no longer simply just be a random chunk that's spit out after an artifact is crushed.
+Instead, each distinct path of the artifact's structure will be turned into a fragment which stores the nodes and connections from that path.
+
+These fragments, instead of being crafted into a new artifact, will be combined with existing artifacts at a **Splicer**.
+This provides interesting gameplay where you can combine artifacts to create more tactically useful artifacts with beneficial or dangerous effects.
+
+The fragments will also scale their artifexium values in relation to the amount research they provide.
+
+### New Equipment
+New equipment (besides the splicer) will focus mostly on manipulating the active nodes of an artifact and interacting with the new mechanics.
+
+**Artifact Glue** is a reagent made from artifexium and when applied to an artifact will repair the durability of nodes on it.
+This provides additional uses for artifexium and ways to extend an artifact's lifespan in the case of beneficial effects that players are using often.
+
+The **Resequencer** simply takes the existing nodes and shuffles them, creating new connections.
+This can completely flip the effects of an artifact and enable new wacky combinations.
+It can also help reach particularly hard to get nodes and allow science to fully unlock the artifact.
+
+The **Arti-nUKer** is a special device that obliterates all active nodes on an artifact.
+The severed connections are automatically merged, fixing any holes created in the structure.
+This is basically a free re-roll of effects paired with easier to activate high-depth nodes.
+
+The Resequencer and Arti-nUKer both serve as mid-tier research to provide optional depth for the truly engaged archeologists, without the boring technical complexity of the traversal distorter.
+
+## Research Generation
+The analysis console UI will show the current research value of the artifact as well as the value it needs to exceed to generate more research.
+
+This will also show the calculation for how the research value is achieved, providing more info and transparency to players.
+
+The research value for an artifact is calculated similarly to how it is now:
+- Unlocked nodes give research based on their effect, stimulus, and depth.
+- Artifacts with no locked nodes grant an additional bonus.
+
+However, there are factors which can damage the research value of an artifact:
+- Nodes with completely degraded durability (gluing the artifact to repair it does not incur this penalty)
+- Missing nodes, such as those from the effect of the Arti-nUKer.
+- Additional nodes, such as from the effects of the Splicer.
+
+Note that the calculation for the last two points is based on the total number of nodes in the original vs. the current artifact.
+If you destroy 2 nodes and then repair it by splicing 2 nodes onto it, you incur 0 penalty.
+
+To actually gain research from the artifact, you must place it on an analyzer and begin the 'research' task in the analysis console UI.
+This begins a 30 second countdown where the artifact must remain on the analyzer, cannot be activated, cannot have any stimuli trigger, and the analyzer must remain powered.
+
+This provides an interesting window wherein sabotage and other such measures can be taken to steal the artifact or otherwise interrupt science.
+
+At the end of this countdown, the research is added into the server and a glorious sound effect plays.
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments/security/proposals/genpop-prisoners.md b/src/en/space-station-14/areas/departments/security/proposals/genpop-prisoners.md
new file mode 100644
index 000000000..a70e69db8
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/security/proposals/genpop-prisoners.md
@@ -0,0 +1,63 @@
+# Genpop Prisoners
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and has not been reviewed or updated.
+It may not fit with the new design requirements.
+```
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| ike709 | :x: No | TBD |
+
+with heavy inspiration from [AndrewMontagne & OracleStation 13](https://github.com/OracleStation/OracleStation/pull/419)
+
+## Design Goal
+
+This is a proposal to redesign the flow of throwing criminals in the brig and their subsequent release. Right now prisoners who aren't permabrigged usually have nothing to do during their sentence except hurry up and wait, and security officers usually have no reason to interact with the prisoner until their time is up and they need to be escorted out of security.
+
+## Current Brig Experience
+
+The current experience for brigging criminals looks something like this (your mileage may vary by map):
+
+1. Criminal is arrested by security officer.
+2. Criminal is brought to security and strip-searched.
+3. Depending on the severity, the criminal is thrown into either an individual brig cell for a few minutes (which is the case for most criminals) or into the permabrig area which (depending on the map) usually allows permabrigged prisoners to interact and/or do things like gardening.
+4. When a non-permabrigged prisoner's time is up, the cell door opens and they can collect their belongings, but they are still trapped in the security department due to airlock access until someone lets them out.
+
+## Turnstiles
+
+Turnstiles are a key feature in the new brig experience that I'm about to propose. Turnstiles are effectively one-way airlocks, allowing travel only in one direction while still allowing mappers or engineers to set normal airlock access requirements to move through them. Here's what they look like on Oracle, including the mapper overlay to show which direction players can move.
+
+![turnstile](https://i.imgur.com/QStUhoA.png)
+
+In this example a player with the relevant access requirements can only move from the north side to the south side of the turnstile. Even ignoring the rest of this design document, turnstiles would still be useful for things such as putting an exit in medbay or being able to leave the disposals room in maintenance.
+
+## Proposed Brig Experience - Genpop
+
+I propose that we completely nuke individual brig cells. All prisoners will now be thrown into a large secure area similar to the permabrig (called "genpop") where they can intermingle, kill eachother, or perform various other mapped-in activities like play arcade games or do basic botany.
+
+Here's an example from OracleStation. Note the turnstiles, the prisoner processing room in the lower part, and the actual genpop prisoner area in the upper part (ignore the armory in the bottom left):
+
+![genpop](https://user-images.githubusercontent.com/202160/35178888-91bb7eb6-fd87-11e7-9040-15a6ef93602c.png)
+
+I highly recommend taking a look at the [OracleStation pull request](https://github.com/OracleStation/OracleStation/pull/419) as it has gifs for most of the things I'm about to describe with words.
+
+This is what the new experience for brigging criminals would look like:
+
+1. Criminal is arrested by security officer.
+2. Criminal is brought to security and strip-searched.
+3. Criminal is given a prisoner ID with their name & the length of their sentence. This ID's access is required to pass through the "entrance" turnstile into genpop, to ensure the security officer processed them correctly.
+4. Criminal is thrown into genpop with all the other prisoners via the "entrance" turnstile, regardless of their crime severity. Individual brig cells and a separate permabrig no longer exist.
+5. The criminal's turnstile access is tied to their prisoner ID. Once their sentence has elapsed, they will now have access on their prisoner ID to pass through the "exit" turnstile from genpop back into the processing area. This means they can leave genpop with no intervention from security officers.
+6. The criminal can retrieve their possessions from the locker in processing using their prisoner ID.
+7. Using turnstiles, the criminal is able to exit genpop, processing, and the main security department entrance without needing a security officer to open doors for them.
+
+## Gameplay Implications
+
+Here's a non-exhaustive list of impacts these changes can have on gameplay, in no particular order:
+
+- Players no longer need help opening airlocks to exit security when their sentence elapses
+- Players now have things to do while they are brigged, whether it's ~~killing~~ interacting with other prisoners or the items/machines mapped in genpop
+- Players could escape early by stealing or trading eachother's prisoner IDs
+- Wardens are now incentivized to actually keep an eye on the brig and its prisoners to prevent fights/prison breaks/shenanigans
+- The brig effectively no longer has a prisoner capacity limit, as individual brig cells are no longer needed
+- Security officers can pass through genpop turnstiles at will with their ID access, allowing them to enter/exit genpop without prisoners tailing them to escape
+
diff --git a/src/en/space-station-14/areas/departments/service/proposals/plant-genetics.md b/src/en/space-station-14/areas/departments/service/proposals/plant-genetics.md
new file mode 100644
index 000000000..9f8074bb8
--- /dev/null
+++ b/src/en/space-station-14/areas/departments/service/proposals/plant-genetics.md
@@ -0,0 +1,55 @@
+# Plant Genetics
+```admonish warning "Attention: Legacy Documentation!"
+This document is ported from before the game-area reorganization and has not been reviewed or updated.
+It may not fit with the new design requirements.
+```
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| deltanedas | :x: No | TBD |
+
+# Overview:
+
+A new CRISPR-like machine for modifying genomes of plants.
+Has a hex editor-like UI where you can seek to a position and it shows a certain number of bases.
+From there you can make modifications e.g. swapping out an A at index 38 for a T. Once you are happy and think your modifications won't kill the plant, create your new seed and plant it.
+Since genome layouts are randomized roundstart this would be no better than current mutagen roulette of just hoping it gets a good trait and doesnt make the plant useless.
+
+To solve gene roulette, the second part of this would be experimentation.
+Get 2 identical seeds with clippers then mutate one a little using unstable mutagen.
+Either the same machine from the start or a separate one can then analyze them and check what genes (bits) are different.
+After a little bit of time it either picks a single random bit, or multiple of them, and tells the player what gene name is at that bit. If the gene has multiple bits it will take some investigation to see which bit it is but that's trivial for yield/potency which can be seen just by clipping it.
+Essentially you keep experimenting on plants to figure out the index of every gene, and tada youve mapped the plant genome and can make gmos with ease for the rest of the round.
+
+# Goals:
+Promote interdepartment stuff by requiring biomass for gene editing:
+- Means there is some cost to minmaxing a plant so you might just have to settle for the important traits
+- If there is no med staff / no bodies to juice you can still grow plants as normal
+- There was some ideas about being able to reclaim biomass from plants so you could use that to kickstart it.
+- Salvage can find biomass on expeditions as a large but irregular source, assuming med doesn't get to it first.
+
+# Gameplay:
+The gene editing would primarily be a window like a hex editor, set a position to seek to and then itll show up to X bases.
+You can modify a base by just typing A C G or T. they map to 00 01 10 and 11 respectively in binary, so for every 2 bits you get a single base.
+From there the player can feed it biomass and print out a fancy new seed with a cost of say 1 biomass per bit modified.
+
+Unstable mutagen would randomly flip bits so you could get an increase of 8 to yield or a decrease of 1 to potency, depends on which bit it flips in an int.
+
+Pollen swabbing, if it still exists, would swap entire gene values rather than operate on a random bit basis.
+
+This might have botanists split up between growing plants for chef and focusing on mapping the genome to get gamer seeds which is cool.
+
+Additionally, instead of the current mutation of a viable bool, a system would be in place where there are bits that set unreasonable pressure temperature or light requirements to grow.
+If a plant suddenly requires being grown in space or a fire you are unlikely to try, but it's still possible if you are extremely determined.
+
+# Components:
+Plant entities would both have GenomeComponent and its own component for handling swabbing/crossbreeding along with copying genes from parent when clipping.
+
+Since only bools and ints can be stored in genomes, chemicals would still need to be in solution container component and mutated manually similar to how its done currently with SeedData chemicals.
+
+# Inspirations:
+
+- life
+
+# Requirements:
+
+Depends on a rework of botany to have plants be ECS.
From 629963ecbf499b802049d0c05a68652ee6a52b30 Mon Sep 17 00:00:00 2001
From: Jezithyr
Date: Sat, 20 Apr 2024 21:38:29 -0700
Subject: [PATCH 23/80] =?UTF-8?q?Fixed=20duped=20proposals=20folder,=20put?=
=?UTF-8?q?=20feature=20proposal=20template=20under=20fea=E2=80=A6=20(#204?=
=?UTF-8?q?)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
…ture proposals heading
---
src/SUMMARY.md | 3 +-
src/en/proposals/deltanedas-exterminator.md | 41 ----
src/en/proposals/deltanedas-plant-genetics.md | 52 -----
.../proposals/deltanedas-signaller-rework.md | 93 --------
src/en/proposals/deltanedas-turf-war.md | 38 ----
src/en/proposals/emogarbage-grid-inventory.md | 72 ------
.../emogarbage-machine-upgrading-rework.md | 90 --------
src/en/proposals/emogarbage-xenoarch-redux.md | 173 --------------
.../proposals/fairlysadpanda-pizzadelivery.md | 84 -------
.../proposals/flareguy-engine-containment.md | 49 ----
src/en/proposals/ike709-genpop-security.md | 60 -----
src/en/proposals/ike709-robusthub.md | 110 ---------
src/en/proposals/ike709-statpanels.md | 74 ------
.../proposals/julian-vasilis-pda-messaging.md | 111 ---------
src/en/proposals/mirrorcult-anomaly-cores.md | 49 ----
.../mirrorcult-cleanup-crew-gamemode.md | 53 -----
src/en/proposals/mirrorcult-rogue-drones.md | 68 ------
src/en/proposals/notafet-atmos.md | 117 ----------
src/en/proposals/tday93-power-generation.md | 127 -----------
src/en/proposals/theshued-thief.md | 98 --------
src/en/proposals/tomleys-game-director.md | 212 ------------------
21 files changed, 1 insertion(+), 1773 deletions(-)
delete mode 100644 src/en/proposals/deltanedas-exterminator.md
delete mode 100644 src/en/proposals/deltanedas-plant-genetics.md
delete mode 100644 src/en/proposals/deltanedas-signaller-rework.md
delete mode 100644 src/en/proposals/deltanedas-turf-war.md
delete mode 100644 src/en/proposals/emogarbage-grid-inventory.md
delete mode 100644 src/en/proposals/emogarbage-machine-upgrading-rework.md
delete mode 100644 src/en/proposals/emogarbage-xenoarch-redux.md
delete mode 100644 src/en/proposals/fairlysadpanda-pizzadelivery.md
delete mode 100644 src/en/proposals/flareguy-engine-containment.md
delete mode 100644 src/en/proposals/ike709-genpop-security.md
delete mode 100644 src/en/proposals/ike709-robusthub.md
delete mode 100644 src/en/proposals/ike709-statpanels.md
delete mode 100644 src/en/proposals/julian-vasilis-pda-messaging.md
delete mode 100644 src/en/proposals/mirrorcult-anomaly-cores.md
delete mode 100644 src/en/proposals/mirrorcult-cleanup-crew-gamemode.md
delete mode 100644 src/en/proposals/mirrorcult-rogue-drones.md
delete mode 100644 src/en/proposals/notafet-atmos.md
delete mode 100644 src/en/proposals/tday93-power-generation.md
delete mode 100644 src/en/proposals/theshued-thief.md
delete mode 100644 src/en/proposals/tomleys-game-director.md
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index a4220a8ab..35a9c9786 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -11,8 +11,6 @@ Meta
- [Docs Example Page](en/meta/docs-example-page.md)
- [Docs are for Discoverability](en/meta/docs-are-for-discoverability.md)
-- [Feature Proposal Template](en/templates/proposal.md)
-
General Development
===================
@@ -37,6 +35,7 @@ General Development
- [Config File Reference](en/general-development/tips/config-file-reference.md)
- [YAML Crash Course](en/general-development/tips/yaml-crash-course.md)
- [Feature Proposals](en/general-development/feature-proposals.md)
+ - [Feature Proposal Template](en/templates/proposal.md)
- [Expected Team Decorum & Usage](en/general-development/feature-proposals/expected-feature-proposal-decorum.md)
- [Work Groups](en/general-development/work-groups.md)
diff --git a/src/en/proposals/deltanedas-exterminator.md b/src/en/proposals/deltanedas-exterminator.md
deleted file mode 100644
index 872d81d03..000000000
--- a/src/en/proposals/deltanedas-exterminator.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Exterminator
-
-| Designers | Implemented | GitHub Links |
-|---|---|---|
-| deltanedas | :white_check_mark: Yes | https://github.com/space-wizards/space-station-14/pull/19946 |
-
-## Abstract
-
-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.
-
-## Goals
-
-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.
-
-
-## Gameplay
-
-While the exterminator has no telecrystals or gear like syndies or ninjas, what they do have is the following:
-
-- 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.
-- 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.
-
-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.
-
-As it only spawns without intervention through a midround event, it can never spawn or have multiple exterminators per round.
-
-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.
-
-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.
-
-## Components
-### Endoskeleton
-
-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.
-
-As the endoskeleton can’t hold guns and is slow, it is an easy target for tiders to finish off with bats and crowbars.
-
-
-## Inspirations
-
-Obviously The Terminator (1984) it’s a classic.
diff --git a/src/en/proposals/deltanedas-plant-genetics.md b/src/en/proposals/deltanedas-plant-genetics.md
deleted file mode 100644
index 5641a9cd5..000000000
--- a/src/en/proposals/deltanedas-plant-genetics.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# Plant Genetics
-
-| Designers | Implemented | GitHub Links |
-|---|---|---|
-| deltanedas | :x: No | TBD |
-
-# Overview:
-
-A new CRISPR-like machine for modifying genomes of plants.
-Has a hex editor-like UI where you can seek to a position and it shows a certain number of bases.
-From there you can make modifications e.g. swapping out an A at index 38 for a T. Once you are happy and think your modifications won't kill the plant, create your new seed and plant it.
-Since genome layouts are randomized roundstart this would be no better than current mutagen roulette of just hoping it gets a good trait and doesnt make the plant useless.
-
-To solve gene roulette, the second part of this would be experimentation.
-Get 2 identical seeds with clippers then mutate one a little using unstable mutagen.
-Either the same machine from the start or a separate one can then analyze them and check what genes (bits) are different.
-After a little bit of time it either picks a single random bit, or multiple of them, and tells the player what gene name is at that bit. If the gene has multiple bits it will take some investigation to see which bit it is but that's trivial for yield/potency which can be seen just by clipping it.
-Essentially you keep experimenting on plants to figure out the index of every gene, and tada youve mapped the plant genome and can make gmos with ease for the rest of the round.
-
-# Goals:
-Promote interdepartment stuff by requiring biomass for gene editing:
-- Means there is some cost to minmaxing a plant so you might just have to settle for the important traits
-- If there is no med staff / no bodies to juice you can still grow plants as normal
-- There was some ideas about being able to reclaim biomass from plants so you could use that to kickstart it.
-- Salvage can find biomass on expeditions as a large but irregular source, assuming med doesn't get to it first.
-
-# Gameplay:
-The gene editing would primarily be a window like a hex editor, set a position to seek to and then itll show up to X bases.
-You can modify a base by just typing A C G or T. they map to 00 01 10 and 11 respectively in binary, so for every 2 bits you get a single base.
-From there the player can feed it biomass and print out a fancy new seed with a cost of say 1 biomass per bit modified.
-
-Unstable mutagen would randomly flip bits so you could get an increase of 8 to yield or a decrease of 1 to potency, depends on which bit it flips in an int.
-
-Pollen swabbing, if it still exists, would swap entire gene values rather than operate on a random bit basis.
-
-This might have botanists split up between growing plants for chef and focusing on mapping the genome to get gamer seeds which is cool.
-
-Additionally, instead of the current mutation of a viable bool, a system would be in place where there are bits that set unreasonable pressure temperature or light requirements to grow.
-If a plant suddenly requires being grown in space or a fire you are unlikely to try, but it's still possible if you are extremely determined.
-
-# Components:
-Plant entities would both have GenomeComponent and its own component for handling swabbing/crossbreeding along with copying genes from parent when clipping.
-
-Since only bools and ints can be stored in genomes, chemicals would still need to be in solution container component and mutated manually similar to how its done currently with SeedData chemicals.
-
-# Inspirations:
-
-- life
-
-# Requirements:
-
-Depends on a rework of botany to have plants be ECS.
diff --git a/src/en/proposals/deltanedas-signaller-rework.md b/src/en/proposals/deltanedas-signaller-rework.md
deleted file mode 100644
index 5f167294b..000000000
--- a/src/en/proposals/deltanedas-signaller-rework.md
+++ /dev/null
@@ -1,93 +0,0 @@
-# Signaller Rework
-
-| Designers | Implemented | GitHub Links |
-|---|---|---|
-| deltanedas | :x: No | TBD |
-
-## Overview
-
-This proposal is for a rework of signals to be very short range (2-5m maximum) and have a separate radio transmission system for long-range controlling of objects.
-
-Linking would effectively be wiring now with its short range.
-
-## Background
-
-Currently you can link 2 items together and they can be used across maps with infinite range.
-
-They can also be nonsensical like linking a door to a microwave. Why would either have long-range transmission?
-
-With a radio transmission system these systems can be implemented more freely allowing for more in-depth gameplay.
-
-## Radio Transmission
-
-This would be the main part of the rework. Radio transmitters would be items that accept signals and send them over radio with a frequency.
-
-Radio receivers then create signals when a radio wave of a certain frequency is received. These would then be linked to objects like doors or microwaves.
-
-Radio frequencies would range be in the VHF range between 100 and 200 MHz, with 0.1MHz of precision. This allows for 1000 different communication channels, plenty for a single round.
-
-In the UI for setting frequency this would mean you can have 100.0 MHz and 100.1 MHz be distinct.
-
-Since radio uses authenticated encryption, signallers can't interfere with it if set to the same frequency.
-
-## Transmitters and Receivers
-
-Radio transmitters either could just be signallers themselves or a new item that can't be manually triggered.
-If they are kept separate, the ui for setting frequency can be shared for both.
-
-Since transmitters can't be manually triggered they would be cheaper to make so making circuits is easier.
-
-Radio receivers would just be a reworked signal trigger, it doesn't make sense to have a door output linked to a grenade which will move around.
-
-Signal triggers have a UI to change frequency to match the signaller/transmitter, then you put it in a grenade or have it linked to something nearby.
-
-Signal triggers would also have a signal sink port for linking to nearby objects.
-
-Communicating across maps would not be possible, but perhaps a tech could be added for a transmitter that can work across maps and over an extended frequency range.
-
-## Interacting with objects
-
-Objects with wire panels like airlocks can have a signaller inserted when the panel is open.
-
-Things with no panel like lights or microwaves can have them space-glued on, which is visible by examining.
-
-Objects can still be linked nearby of course, but with shorter range. Maps with auto-bolting airlocks would still be fine.
-
-## Gluing
-
-If an item matching a whitelist is glued to an object like a light, APE or emitter, it is allowed to use its signal ports.
-
-Glued items can be examined by anyone, only removed by spraying some kind of solvent on it, maybe even space lube.
-
-## Example setup
-
-A signaller set to 133.7MHz is linked to an airlock's door status port.
-
-To prevent the signaller from being disconnected by someone moving it, it is then inserted into the wire panel.
-
-A signal trigger with the same frequency is placed in a modular chem grenade across the station.
-
-When the door opens, HIGH is sent over radio and the grenade explodes.
-
-For a light, the signaller is space-glued onto it. This might have a unique sprite layer.
-
-## Implementation
-
-Frequencies would just be ushorts, clamped between 1000 and 2000. Essentially 1 place of fixed precision.
-
-Transmission would use device network, but not the device linking packets. These can have unlimited range but on a single map.
-
-Signal triggers handle device network radio packets and only use them if they have the same frequency.
-
-Device linking can then be changed to have a very short range (200m seems to be the default currently?) to promote usage of radio systems.
-
-Should be easy to add a network that says a device can only communicate if it is glued onto it, which APE and stuff would use but not doors.
-
-### What I Stole From
-
-In TG I think it uses a similar setup but with a code as well as frequency.
-
-I decided not to have a code to make the system less complex and a bit easier to mess with, you only need to guess a frequency not a code.
-
-In TG it's also just the same item for receiving and sending, you attach a signaller to a grenade to have it trigger it.
-I don't think this is the best way to do it.
diff --git a/src/en/proposals/deltanedas-turf-war.md b/src/en/proposals/deltanedas-turf-war.md
deleted file mode 100644
index d1c83f19d..000000000
--- a/src/en/proposals/deltanedas-turf-war.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# Turf War
-
-| Designers | Implemented | GitHub Links |
-|---|---|---|
-| deltanedas | :warning: partially | [#23290](https://github.com/space-wizards/space-station-14/pull/23290) |
-
-## Abstract
-
-Turf war is a sub-gamemode that can be present in others (traitor, revolution; similar to thief).
-
-Players must use spray painters to tag up turf for their respective departments. Whichever department gets the most doors sprayed at the end wins!
-
-## Goals
-
-It is intended to be a small bit of fun seen in some rounds, but not completely taking it over the round like revolution.
-
-Turf taggers must **not** be selected from other antagonists in the round (could be exclusive with traitor, to keep it as a nonantag side fun gamemode.
-
-Unlike most gamemodes, players selected can be in command and sec (since they aren't antagonists).
-
-However, command staff will tag for their respective departments **and not command doors**. Since cap and hop don't govern individual departments, they can't be picked.
-
-## Gameplay
-
-Players are not antagonists (unless they are from another role) so they should not immediately start killing everyone, following escallation rules.
-
-Naturally there will be skirmishes but it won't be as bloody as traitor assassinations or revolutions.
-
-Each turf tagger has an objective to spray the most doors, which is either 100% (you are winning) or a % of whoever is winning.
-
-On round end the number of doors each turf tagger has is shown, in order of who got the most.
-
-Only one tagger is selected from each department at most, but they may recruit coworkers IC (not a flash) to join the turf war. Spray painters are available in YouTools so nobody is left out.
-
-
-## Inspirations
-
-TG families or whatever its called now, but with spraying doors.
diff --git a/src/en/proposals/emogarbage-grid-inventory.md b/src/en/proposals/emogarbage-grid-inventory.md
deleted file mode 100644
index 0600407a3..000000000
--- a/src/en/proposals/emogarbage-grid-inventory.md
+++ /dev/null
@@ -1,72 +0,0 @@
-# Grid Inventory
-
-| Designers | Implemented | GitHub Links |
-|---|---|---|
-| EmoGarbage | :white_check_mark: Yes | https://github.com/space-wizards/space-station-14/pull/21931 |
-
-Credit to the SS13 server Fields of Fire, whose inventory overhaul served as inspiration for the UI.
-
-## Overview
-
-Grid inventory is intended to be a replacement for the current inventory backend and UI.
-It encompasses both an internal rewriting of storages, wherein they are classified by geometric shapes, as well as a redesign of the UI, aiming to translate the internal logistics of the system in an immediately understandable way.
-Under the system, storages will consist of grids made up of tiles and items will be small items that can be moved around and fit into the grid.
-
-## Storage Pains
-
-Laying out what's wrong with the current storage system is important, because inventories--and for the purpose of this document, inventory refers to any given storage container, not the players' hands and clothing HUD--fail in subtle and unexpected ways.
-The failures can be divided largely into two categories, mechanical and visual, and both show the unique ways in which a core system can underperform and in turn erode more central mechanics.
-
-In terms of the mechanical failings, those which call for the rewriting of the core of the system, the most evident is the inability to represent objects of unorthodox or strange shape.
-Whether it be a numerical size or an enum, it is impossible to communicate the spacial properties of something like a broom or a life preserver.
-Inventories cannot be long and thin or made up of many smaller sections.
-There is a lot of genuine interest in nuance in the problem of storing an object: it exists as a microcosm of greater questions of the value of what you carry and if it can be stored in an efficient manner.
-As the system exists currently, the "efficiency" of storage is not a concept that can be explored, which is a shame.
-
-On a more surface level, the presentation and interactions of a list inventory is also laden with issues.
-By existing as an infinitely scalable list, containers are forced to express the sizes and capacity numerically, relying on exposing objectively meaningless numbers in order to communicate scale.
-Furthermore, lists are bad at displaying images at a scale that is easily understood (due to their properties of being scalable) and thus rely on things like text, which simply saturates what should be a very simply HUD element with lots of text and numbers.
-Lists are also frequently used to fill up large chunks of the screen, which genuinely looks terrible.
-
-Ideally, a perfect storage system should not only be able to handle weird sizes and shapes of containers and items alike, but also visually convey this in a way that is immediately able to be understood by a new player without being overly reliant on text and numbers.
-
-Thing goes in bag is simple: it should feel simple to do.
-It should never feel sprawling or overwhelming or like you're scanning your screen for crap.
-
-## Grid Inventory
-
-Our solution? A to-scale HUD element that can represent uniquely shaped item's as well as display the size of things in an immersive and immediately understandable way.
-
-![](../assets/images/grid-inventory/in-game.png)
-
-### Items
-
-Items in grid inventory are a deviously simple.
-They retain the ItemSize enum from the current system, but gain an additional `inventory shape`.
-This is just the shape the item takes up in the grid and it additionally serves to codify the hidden weight mechanics of the current inventory in a more intelligent way.
-Rather than tiny items having a weight value of 1, they simply take up a single square.
-Items would have reasonable default sizes inferred from the current weight values of items with an optional specifier for other custom shapes.
-
-![](../assets/images/grid-inventory/shape-examples.png)
-
-Inside of the inventory, you'd be able to manually move around and rotate items, allowing gaps to be filled and space optimized with proper planning.
-You'd also be able to intuit how much of the inventory an item fills from a simple glance, since the volume is of the container is represented visually.
-
-### Storage
-
-![](../assets/images/grid-inventory/grid-example.png)
-
-For the most part, storages exist as literal translations of the current values.
-A 28 capacity simply becomes a 7x4 box.
-In terms of balance, the numerical values of the different items and storages remains the exact same.
-The only difference is having to place the items into the bag and organize them to potentially make room.
-
-Of course, putting an item in your bag will automatically try and orient it within the grid, not allowing it only if there's no room for it to fit.
-This means there's an equal measure of convenience in terms of picking items quickly, only being a hindrance when trying to fit an unwieldy object.
-
-The hotkeys for quickly taking items in and out of bags will remain identical, simply remembering the order of inserted items and taking them out in the reverse order.
-
-### A Brief Aside About Slots
-
-For slot-based storage, like belts, the UI will remain the same, but simply with standardized item sizes.
-A 7 slot belt is a container with 7 squares and every item takes up only a single square. This loses out on the benefits of the scaling, but it integrates well enough and conveys the same information as the previous system, so it's kinda moot.
\ No newline at end of file
diff --git a/src/en/proposals/emogarbage-machine-upgrading-rework.md b/src/en/proposals/emogarbage-machine-upgrading-rework.md
deleted file mode 100644
index 79f059be7..000000000
--- a/src/en/proposals/emogarbage-machine-upgrading-rework.md
+++ /dev/null
@@ -1,90 +0,0 @@
-# Machine Upgrading Rework
-
-| Designers | Implemented | GitHub Links |
-|---|-----------------------|------------------------------------------------------------------------------------------------------------------------------------------------|
-| EmoGarbage | :warning: Partially | [#23202](https://github.com/space-wizards/space-station-14/pull/23202), [#22233](https://github.com/space-wizards/space-station-14/pull/22233) |
-
-## Overview
-
-Upgrades as a whole are somewhat integral to science as a department.
-They basically exist to produce upgraded versions of various items and tools.
-However, when it comes to upgrading the machines around the station, there are some issues.
-
-It's not a stretch to say that machine upgrading is in a state of constant irrelevancy.
-Even after a slew of additions and support added for close to 20 different machines, the system failed to become the science subdepartment I had hoped, rather becoming a strange task that would occasionally be done by a select few players.
-
-The system suffers from a few core issues, which I will highlight briefly.
-#### RND Integration
-Machine parts predate the new discipline system that RND now functions on.
-While in the past, getting higher tier parts was really trivial, now, with the heavy randomization implicit in the system, it's pretty common to go a long time before receiving even one part upgrade.
-
-It also means that all machine part upgrades, which can affect machines between every department in the game, are relegated to a single discipline.
-This not only makes that single discipline (experimental) significantly better than most others, but it also means that other disciplines that could have new upgrades get snubbed by the machine part upgrades.
-
-#### Discoverability
-By the nature of machine parts, it's really difficult to tell when and where they'll have an effect.
-Of course, if you have already built the machine, you can physically examine it to determine if it has upgrade potential, but this knowledge isn't readily available at all when you unlock the parts.
-Additionally, the line between a machine and not a machine is very much a technical one that players are unlikely to intuit.
-
-Previously, the methodology for making upgrades discoverable was a tactic of complete coverage: every machine _must_ have an upgrade.
-Otherwise, using higher tier parts to upgrade a machine could result in no difference at all, which would be frustrating for players.
-This is obviously not ideal however, since some machines really just don't need upgrades.
-
-A perfect system would make players instantly aware of what machine they can improve the moment they are able to, rather than requiring a ton of trial and error discovery.
-
-#### Balancing
-Machine parts exist as simply numerical values.
-Each tier is basically just a number that goes up with little else to distinguish it.
-This means that, to implement an upgrade, the simplest and most logical way of doing it is simply increasing some value on a component.
-
-This is not to say that it is impossible to do anything deeper, but the system as a whole has absolutely no support for that, and adding support for it is really not feasible due to the nature of being to swap parts so trivially.
-This makes having additional 'side-grade' features (which can be integral to balance) very difficult to implement.
-
-Furthermore, having 4 distinct levels of upgrades makes balancing this very difficult, with a lot of things getting absurdly strong in the later tiers.
-This is very prominent with a lot of machines that have 'useless' upgrades (the blender blending things instantly comes to mind) but it's also tough to balance a numerical value that is simultaneously worthwhile when in the 2-3 range, but not overpowered in the 3-4.
-
-## Discrete Upgrades
-My proposed solution to this issue is **discrete upgrades**.
-This isn't really a formalized system but rather a guideline for how to better make "upgrades" without machine parts and the like.
-
-Discrete upgrades are, quite plainly, machines that look and have similar names to existing ones while performing their task better.
-A discrete upgrade to a microwave might simply be a 'macrowave' that has a glossy black finish and an absurd radiation sound while cooking food twice as fast.
-
-These machines would simply be unlocked like any other science machine: via unlocking the corresponding technology in the appropriate discipline.
-This helps with discoverability, integration, and balancing, since now these upgrades can be in disciplines relevant to them while also being able to have custom unlock prices and tier restrictions.
-Furthermore, before you even unlock the tech, you are made aware of what upgrades you are getting via the descriptions of what is unlocked.
-
-Additionally, these new entities, since they are completely different than their base counterparts, can easily have new components added to them in YAML to allow for new functionality such as emitting radiation, heat, or any other behavior.
-This is a powerful tool for adding downsides to balance potentially strong upsides.
-
-Unlocking **Geiger's Food Prep Science** and being able to build the **macrowave**, which instantly cooks your ramen while dousing you in lethal radiation, is a far more engaging and discoverable system than simply getting **Super Parts** and waddling over to the kitchen to allow the same old microwave to cook your food instantly.
-Just simply having different audio/visual stimuli makes the upgrades more unique and recognizable to players.
-
-## Machine Parts
-Tier 1 machine parts, that being the capacitor, matter bin, and manipulator, will most likely remain in the game.
-It might even be worthwhile to bring back the laser and scanning module if we so please.
-
-These parts won't have any unique functionality.
-They'll simply remain as a small item used in various constructions for variety, which is always nice.
-
-The RPED, being a somewhat core concept of machine-part-based upgrading, will likely just be removed.
-It doesn't really fit in with the way discrete machines work and the functionality of placing in machine parts into a frame is really not enough to justify it existing.
-
-Likewise, the technologies for higher tier parts as well as the parts themselves will also be removed.
-There's not really a purpose to them and, as we saw before upgrades had implementation, they were frequently a source of confusion as to what their higher tier actually did.
-
-## Flatpacks and the Flatpacker
-A common concern that has been voiced about the removal of machine parts is that it makes these upgrades harder to access for the average player.
-This is a pretty fair criticism: building new machines is a fairly intensive process, requiring a variety of tools, parts, and materials.
-It's a fair to expect that the average service worker or cargo tech may not have the means to build upgrades in scale.
-
-The solution to this is a concept already used in the game: **flatpacks**.
-
-You may be familiar with these from station beacons or the AME shielding: these are small boxes that can be unpacked via a multitool, turning into a full-sized machine.
-These are an ideal way to allow non-technical roles to build machines easier, since they require very little skill to use.
-
-The way that flatpacks will be constructed is through a new science machine, called the **flatpacker**.
-The flatpacker simply takes in a machine board and an amount of materials equal to the construction cost (with a small addition in exchange for the convenience) and creates a flatpack for that machine, leaving the board.
-
-This makes the flatpacker the ideal way to make compact machines that can be set up trivially as well as making a large amount of machines in bulk that can be transferred easily.
-This is good for scenarios like bringing over a bunch of hydroponics trays to botany, or making a bunch of recharging stations and setting them up around the station quickly.
\ No newline at end of file
diff --git a/src/en/proposals/emogarbage-xenoarch-redux.md b/src/en/proposals/emogarbage-xenoarch-redux.md
deleted file mode 100644
index a14c08051..000000000
--- a/src/en/proposals/emogarbage-xenoarch-redux.md
+++ /dev/null
@@ -1,173 +0,0 @@
-# XenoArch Redux [3MOArch]
-
-| Designers | Implemented | GitHub Links |
-|-----------------|---|---|
-| Thee EmoGarbage | :x: No | TBD |
-
-## Overview
-
-This proposal aims to re-imagine the science subdepartment of XenoArch and Artifacts in general in an effort to give them more depth, and utility.
-This will be accomplished by changing node traversal to add more player agency, improving in-game tools for categorizing and understanding artifact structure, and adding additional equipment that makes manipulation more interesting.
-
-The ultimate goal is to redesign the system so players can better understand how artifacts work and to allow greater utility and mechanics to arise out of artifacts.
-XenoArch should feel like unlocking the sprawling secrets of an artifact while additionally gaining points as a secondary reward for the research.
-
-_This redesign lends partial inspiration to Goon's artlab as well as Noita's customizable wands._
-
-## Background
-As it is now, artifacts consist of interconnected nodes, each one carrying an effect and a trigger.
-The effect is just some crazy behavior that happens in response to the trigger, which is just some kind of generic action taken upon the artifact.
-
-These nodes form a tree, wherein each individual node's depth within this tree determines the craziness of the its effect and trigger.
-An artifact has a single node which is active, which is what determines the current effect and trigger which must be done.
-
-Moving to another node requires the completion of the current node's trigger and is semi-random in nature.
-
-While the core concept of XenoArch is interesting and has decent integration with salvage and cooperation for collecting tools for triggers, there are also many situations where players feel as if they lose the ability to meaningfully interact with them.
-
-I'll outline some of the core issues here:
-
-### Randomness
-Artifact generation is completely random, but so is the activation of effects.
-Players cannot meaningfully control which effects they activate and even the limited tools they have like the traversal distorter are extremely esoteric and don't actually provide meaningful control.
-
-The result of this is that while many effects could potentially be extremely useful and provide players interesting means of interacting with their environments, there's no way to actually harness of control the randomness to produce those interesting outcomes.
-At best, you simply re-trigger a beneficial effect several times and reap the rewards in that way.
-
-### Lack of Complexity
-Artifacts are primarily dictated by a single effect with the occasional mix-up of having permanent effects (many of which are underwhelming).
-Activation stimuli are similar: the only sliding scale to adjust with how difficult something is to activate is just how hard it is to do that singular trigger.
-
-Since these triggers are always placed in isolation, unless the effect is having some pronounced impact on the crew's ability to trigger the artifact, triggers mostly devolve into incredibly simple and routine tasks.
-
-A water trigger should have lots of depth, but it instead is mostly just walking in with a cup of water and splashing it, which is really the most boring way to engage with something like that.
-
-### Lack of Progression
-Artifacts have an innate progression in the form of the scaling of nodes, which is mostly built around increasingly difficult triggers and more dangerous and wacky effects.
-This is a good start for a system like this, but the unfortunate reality of it is that the scaling isn't pronounced enough to often feel like a deviation from the early-depth nodes.
-
-Especially when taken in with randomization of artifacts, you can oftentimes just get subpar generation that flounders in weak effects that don't feel like a progression in research.
-
-## Artifacts
-I'll use the element of a [tech tree](https://en.wikipedia.org/wiki/Technology_tree) as a reference to explain the new generation.
-
-Each node is essentially an upgrade in a tech tree.
-The structure can be described as a typical tech tree structure (a [directed acyclic graph](https://en.wikipedia.org/wiki/Directed_acyclic_graph)) but without the presence of the first element in the graph.
-
-Just like the current system, all of these nodes have a trigger and an effect associated with them.
-However, you do not 'move' to a node like the current system, but you instead permanently unlock it like a tech tree.
-
-And just like a tech tree, unlocking a node has a cost associated with it.
-The 'cost' is the activation of all of the triggers of the nodes in that path--that is, all of the nodes that needed to be unlocked in order for the current node to become available.
-
-In this situation, the 'active' nodes are the nodes in each path that have the highest tier.
-These are the nodes that will produce effects when they are activated.
-The remaining nodes are classified as 'latent'--unlocked but not creating any effects when the artifact is activated.
-
-All remaining nodes are simply locked and have no behavior.
-
-### Activation and Unlocking Nodes
-The activation of an artifact is now something that is distinct from simply triggering a node in the old system.
-
-Activating an artifact is simply achieved by using it in hand, clicking on something, or other context interactions.
-Doing this simply causes all the effects of the active nodes simultaneously.
-
-By making many effects happen at once, they can combine in novel ways and increase the utility and chaos of the artifact, greatly improving on the current system where lackluster nodes can seem to have 0 effect at all.
-
-As a balancing factor, each node of the artifact now has a durability.
-Activating an artifact degrades the durability of all of the active nodes.
-When the node is fully degraded, it no longer produces any effect when activated.
-
-The durability can be repaired using special equipment (which will be elaborated on further later).
-
-In exchange easier activation, unlocking nodes is now more complex.
-To unlock a node, you must provide the stimulus for that node as well as the the stimuli for every node below it in its path (the path being all of the nodes that had to be unlocked in order to reach the current node).
-
-Once the first stimulus is provided, an activation period (roughly 10 seconds) begins wherein all the stimuli activations will be recorded.
-At the end of that period, if the stimuli recorded _exactly match_ a node's required stimuli, it will be unlocked.
-
-```admonish info
-Note that if you need stimuli A, B, and C but you instead provide A, B, C, and X, the node will not be unlocked.
-It must be an exact match and not simply a superset.
-```
-
-Once unlocked, the node's effect will occur while a small animation and sound effect playing, giving feedback to the players that something has occured.
-
-## Equipment
-
-### Analysis Console
-The artifact analyzer and analysis console will be improved to no longer have any kind of delay and to show significantly more information
-
-The console UI will now visually draw all the nodes in the structure, using lines to connect them.
-All unlocked nodes will have basic information such as stimuli, effects, depth, research value, durability, and whether or not the node is active.
-This info can be accessed by clicking on the node in the UI, which will show a small window.
-
-Locked nodes that are connected to unlocked nodes will be given a limited information display, showing only the stimuli and the effect.
-This allows players to have a limited strategy for the nodes they want to unlock.
-
-### Handheld Scanner
-The handheld node scanner will be used to check information on the current active nodes of the artifact.
-
-Clicking on an artifact with the handheld scanner will take a "snapshot" of it which can be viewed in a UI.
-This gives similar info as the analysis console but is limited to the active nodes of the artifact.
-
-The scanner now gains a lot of utility as being able to quickly assess the state of an artifact without needing to bring it to science.
-Being able to check the durability also helps when actively using the effects on the go.
-
-The scanner also has the ability to view the node structure of artifact fragments, which can be useful for sifting through them when trying to splice artifacts.
-
-### Artifexium
-Artifexium, which previously activated artifacts, will now serve as a "dummy" stimuli when applied during an activation period.
-
-For example, if stimuli A, B, and C are needed, but only A and B are provided, spraying artifexium will substitute the non-existent C stimulus and unlock the node.
-
-If there are multiple nodes which could be unlocked by a the artifexium (say, a node needing stimuli ABC and one needing stimuli ABD), one will simply be unlocked at random.
-
-### Artifact Fragments
-Artifact fragments will no longer simply just be a random chunk that's spit out after an artifact is crushed.
-Instead, each distinct path of the artifact's structure will be turned into a fragment which stores the nodes and connections from that path.
-
-These fragments, instead of being crafted into a new artifact, will be combined with existing artifacts at a **Splicer**.
-This provides interesting gameplay where you can combine artifacts to create more tactically useful artifacts with beneficial or dangerous effects.
-
-The fragments will also scale their artifexium values in relation to the amount research they provide.
-
-### New Equipment
-New equipment (besides the splicer) will focus mostly on manipulating the active nodes of an artifact and interacting with the new mechanics.
-
-**Artifact Glue** is a reagent made from artifexium and when applied to an artifact will repair the durability of nodes on it.
-This provides additional uses for artifexium and ways to extend an artifact's lifespan in the case of beneficial effects that players are using often.
-
-The **Resequencer** simply takes the existing nodes and shuffles them, creating new connections.
-This can completely flip the effects of an artifact and enable new wacky combinations.
-It can also help reach particularly hard to get nodes and allow science to fully unlock the artifact.
-
-The **Arti-nUKer** is a special device that obliterates all active nodes on an artifact.
-The severed connections are automatically merged, fixing any holes created in the structure.
-This is basically a free re-roll of effects paired with easier to activate high-depth nodes.
-
-The Resequencer and Arti-nUKer both serve as mid-tier research to provide optional depth for the truly engaged archeologists, without the boring technical complexity of the traversal distorter.
-
-## Research Generation
-The analysis console UI will show the current research value of the artifact as well as the value it needs to exceed to generate more research.
-
-This will also show the calculation for how the research value is achieved, providing more info and transparency to players.
-
-The research value for an artifact is calculated similarly to how it is now:
-- Unlocked nodes give research based on their effect, stimulus, and depth.
-- Artifacts with no locked nodes grant an additional bonus.
-
-However, there are factors which can damage the research value of an artifact:
-- Nodes with completely degraded durability (gluing the artifact to repair it does not incur this penalty)
-- Missing nodes, such as those from the effect of the Arti-nUKer.
-- Additional nodes, such as from the effects of the Splicer.
-
-Note that the calculation for the last two points is based on the total number of nodes in the original vs. the current artifact.
-If you destroy 2 nodes and then repair it by splicing 2 nodes onto it, you incur 0 penalty.
-
-To actually gain research from the artifact, you must place it on an analyzer and begin the 'research' task in the analysis console UI.
-This begins a 30 second countdown where the artifact must remain on the analyzer, cannot be activated, cannot have any stimuli trigger, and the analyzer must remain powered.
-
-This provides an interesting window wherein sabotage and other such measures can be taken to steal the artifact or otherwise interrupt science.
-
-At the end of this countdown, the research is added into the server and a glorious sound effect plays.
\ No newline at end of file
diff --git a/src/en/proposals/fairlysadpanda-pizzadelivery.md b/src/en/proposals/fairlysadpanda-pizzadelivery.md
deleted file mode 100644
index 2939ca94f..000000000
--- a/src/en/proposals/fairlysadpanda-pizzadelivery.md
+++ /dev/null
@@ -1,84 +0,0 @@
-# Arnold's Pizza Delivery Service
-
-| Designers | Implemented | GitHub Links |
-| -------------- | ----------- | ------------ |
-| FairlySadPanda | :x: No | TBD |
-
-# Arnold's Pizza Needs Delivery Critters
-
-- Alone?
-- Gullible?
-- Poor?
-- Unaware of our reputation?
-
-If most/all of these apply to you, _or_ we've successfully kidnapped you from your home, then Arnolds Pizza has a job with your name on it!
-
-We need delivery critters willing to do one of the most difficult and thankless tasks in known space: delivering pizzas to NanoTrasen employees!
-
-NanoTrasen knows we make the best pizza in the galaxy*. That's why they have an exclusive contract with us to fulfil their Random Reward Pizza employee satisfaciton scheme. However, NanoTrasen's boutique, black-ops and (frequently) badly-maintained space stations are both challenging to access and deliver to. The fell-off-a-back-of-a-van BlueSpace teleporation devices that we use for such challenging customers are both extremely unethical *and\* have a carry-limit small enough that we can't send a full-sized sapient creature through with our KeepWarm pizza boxes in tow!
-
-That means there's a _unique_ and _exciting_ opportunity for small, light, _expendable_ critters in our delivery services. Join today, and we promise that we'll let you leave afterward. Just remember to get that receipt!
-
-\*As do the Syndicate, but we don't tell them that.
-
-# Overview
-
-Building on positive player feedback from the April Fools Legally Distinct Space Ferret neutral antagonist, this design document outlines a role that sees the player play as a small, agile critter on a time-limited mission to complete a delivery task to a member of the crew. Success is delivery and retreival of a signed receipt: failure is a tragic death due to the compromising of the nuclear fission heater that the delivery company has strapped to said critter's back.
-
-## Player Profiles
-
-- **Pop-In** wants to pop-in to to the round for a few minutes and interact with the crew, but doesn't have time to stick around for the evac shuttle.
-- **Cutesy Gamer** wants to play as a cute critter with more than just roleplaying to do.
-- **Comedy Gamer** wants to be placed in a tense, absurd situation where their game knowledge can shine to get a challenging goal done.
-
-## How it works
-
-- A mid-round ghost role of "Pizza Delivery critter" allows a player to spawn as a cute sapient critter similar to a monkey or kobold at appropriate spawns decided by the map creator, or by mimicing vent critter spawning should this retrofitting have not taken place.
-- This critter is given two sets of information:
- 1. The identity of its delivery target, including their face, profession and name.
- 2. The amount of time they have to complete the delivery before the KeepWarm heater on their back violently explodes.
-- The timer is constantly displayed at the bottom of the screen, above the equipment bar. This is a reference, appropriately enough, to _Pizza Tower_.
-- The critter is a neutral antagonist with one objective:
- - Get a signed reciept from the target before time runs out.
-- The critter's target must be alive and not in crit to be chosen.
- - If the target is gibbed or becomes SSD for any reason during the delivery attempt, Arnold's Pizza declares the order void and the player is freed from the timer. If this happens, they get to eat the pizza. This is the "neutral" end condition for this antag - the player will not greentext, but they do not get round-removed.
-- The critter the player plays at has the following abilities:
- - Small creature hitboxes, allowing it to slide underneath most doors. Arnold's Pizza has extensive experience dealing with NT stations and has engineered its delivery critters to be able to actually have a chance of delivering to Urist McScientist who is sitting behind three secure airlocks.
- - The following item slots:
- - Hat (containing a branded red Arnold's Pizza cap that itself contains a tiny item storage slot, containing a pen)
- - Mask
- - Belt (containing a branded o2 canister)
- - Pocket (with a branded gas mask)
- - PDA/ID Card
- - One hand slot
- - The critter is not especially vulnerable to any damage type, breathes oxygen, but has no capacity at all to wear a spacesuit. They are provided with the means to survive atmos failure, though, preventing frustrating spawns.
- in the event the station is spaced, but they will die to barotrauma somewhat quickly.
- - The critter has the same amount of health as a monkey.
- - The critter nyooms - that is, they have a higher-than-average base and running speed, appropriate for a frantic delivery vehicle.
- - The critter only speaks in cute noises unless given cognizine.
-- The critter has the ability to print out a receipt for its order. This receipt contains the same information the critter was given regarding the target's identity.
-- The receipt has a space for a signature. The only way this signature can be filled in is by the target. It needs to be filled in by using a pen (of any kind) on the receipt.
-- The receipt must be handed back to the critter, who then must feed it back into the heater to retrieve the pizza. This counts as a victory and allows the critter to greentext.
-- The pizza is one of Arnold's specials. The pizza will have one of the following properties:
- - Dank: contains, as you'd expect, dankness, and gives the user hallucinations (cannabis).
- - Healthy: like the current Arnold's pizza item, this contains a powerful healing agent (omnizine).
- - Stimulants: this pizza is loaded with sugar and makes the target nyoom for a medium period.
- - Hot N Spicy: eating the pizza causes the target to set on fire.
- - Space Carp Pizza allows the target to avoid pressure damage for a medium period.
- - Classic: (PRE WOUND MED) causes the target to detonate. (POST WOUND MED) causes the target's limbs to fly off.
- - All of these pizzas have a "paper-oni" pizza variant for moths to eat.
-- The pizza types have clear labels on their boxes and unique descriptions, but do not overtly say what they do. The positive-effect pizzas are weighted more likely to appear than the negative ones, with the Classic pizza being a rare chance.
-- If the critter fails to deliver the pizza in the time limit, it explodes. This explosion is faked - it gibs the critter but convers no damage to anyone else standing nearby, even on the same tile, to prevent this feature being abused to suicide bomb people.
-- It is possible for a member of the crew with bomb disposal knowledge to disable the KeepWarm heater, thus saving the critter's life. If this occurs, the critter cannot greentext.
-- If the target is in crit or cuffed, using the printed receipt on them whilst the critter has a pen in their pocket allows the critter to forge the signature, greentexting.
-- If the critter has delivered its pizza, it can become eligible to deliver another pizza again later in the round provided the pizza delivery event is rolled again (or if an admin is feeling cruel).
-- The critter always has the option of aborting the mission and teleporting back off the station, to avoid feel-bad moments where the objective is undeliverable, the station is in too bad a state to attempt a delivery, etc.
-
-## Traitor/Nukeops Gameplay
-
-- The Syndicate also have an exclusive contract with Arnold's Pizza, and they leverage that to do a little trolling and help themselves out.
-- A traitor or nukie can order a pizza delivery for themselves or a member of NanoTrasen crew. If they do this, they can specify what exactly the critter is going to deliver. This includes a new, exciting flavour: a bomb with a fuse that looks like it fell out of a Looney Tunes cartoon. The bomb is much too heavy for the critter to hold, and they drop it immediately.
-- This bomb detonates a few seconds after the critter has retrieved it from its KeepWarm heater, doing moderate damage to the station in the process.
- - This is a reference both to Looney Tunes and the famous "sometimes you just can't get rid of a bomb" sketch from the Adam West Batman TV series.
-- The critter is not told they are delivering a bomb or that they're working for the Syndicate, and there's no metagameable way to know if a pizza delivery is legitimate or a trap.
-- This mechanic makes sure that there's a theoretical reason that a player may refuse a delivery.
diff --git a/src/en/proposals/flareguy-engine-containment.md b/src/en/proposals/flareguy-engine-containment.md
deleted file mode 100644
index a02608940..000000000
--- a/src/en/proposals/flareguy-engine-containment.md
+++ /dev/null
@@ -1,49 +0,0 @@
-# Engine Containment Safeties
-
-| Designers | Implemented | GitHub Links |
-|---|---|---|
-| Flareguy, CptJeanLuc |:x: No | TBD |
-
-## Overview
-
-This proposal aims to make sabotaging the primary engines (the singularity and tesla) much, *much* harder - possibly to the point of even being able to be theoretically considered an IC issue, provided you set aside the fact that it is one of the most antagonistic things you could possibly do.
-
-## Background
-
-[This is mainly based on a brainstorming session held in discord,](https://discord.com/channels/310555209753690112/1008709214006427689/1201664586512871435) with some additional things added as I went along.
-
-Despite the round-ending damage these engines can cause, the amount of effort needed in comparison to make them break containment is minimal. By cutting a single wire or turning the PA's particle strength above 1, you can instantly force a shuttle call.
-
-This not only makes it a pretty unbalanced & simplistic interaction for antagonists, but also makes it extremely potent for griefing. It's practically just a "kill station" button with no real safegaurds other then needing engineering access.
-
-## The Safegaurds in Question
-
-- **Particle accelerators are now simplified to on/off instead of having strength.**
-
-In SS13, instead of being a "make the singularity break containment" button, higher particle strengths meant that the singularity would sustain itself at a certain stage. There's not really much value in this, though - you're practically just choosing between "do I want more power or do I want less power," as the added danger of a bigger singularity is incredibly negligible.
-
-This includes the emag behaviors's removal. If you want to loose the engine, you're going to have to put in real effort.
-
-- **Wire Power Monitoring Thingamaob**
-
-A device that mounts to a power network, and monitors if it loses power or is otherwise disconnected from the network. If it does, the object will make a chat message over the engineering channel informing them of the disconnected terminal.
-
-This also helps curb mass-wirecutting (another very easy-to-abuse mechanic.) Engineering can install these in other places and try to cooperate with security to catch a criminal, or just respond to the alarm and repair it when it happens.
-
-People looking to mess with wire nets with the monitor installed will need to get creative - either by using explosives to detonate the wire monitor to prevent it from sending a signal, stopping power from being generated entirely as a coverup, or just by stealing the monitor itself and getting the hell out of there before you can be found.
-
-- **Containment Field Alarms**
-
-The containment fields in the engine room now come with a pre-installed upgrade that lets them broadcast if they are losing power. This would function similarly to the the supermatter alarm from /tg/station; once the containment field starts losing power it will broadcast a message over the engineering channel, and once it's under a certain threshold (say, 2 minutes left of power out of a total of 5,) it'll start broadcasting over common. This is to give the crew a fighting chance to stop whoever is messing with the singularity, and cannot be prevented unless you get a radio jammer in range of all of the containment fields.
-
-To reiterate further, this is a feature that not all containment fields will have. Upgrading a regular containment field with a special upgrade chip should be possible.
-
-- **The Generators Themselves**
-
-This wasn't discussed in the inital discord conversation, but is probably nessecarry, since you can trivially just move a generator in front of the PA and have it instantly loose without having to deal with any containment proceedures. The only reason this probably isn't utilized more often is because raising the PA strength is easier.
-
-When being fired at with a particle accelerator, the generators will broadcast a message over engineering communications:
-
-`A (singularity/tesla) generator is being initalized at (coordinates!)`
-
-Initializing the generators should take approximately 40 seconds or so, to give people time to respond.
diff --git a/src/en/proposals/ike709-genpop-security.md b/src/en/proposals/ike709-genpop-security.md
deleted file mode 100644
index 41e19b75b..000000000
--- a/src/en/proposals/ike709-genpop-security.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# Genpop Security
-
-| Designers | Implemented | GitHub Links |
-|---|---|---|
-| ike709 | :x: No | TBD |
-
-with heavy inspiration from [AndrewMontagne & OracleStation 13](https://github.com/OracleStation/OracleStation/pull/419)
-
-## Design Goal
-
-This is a proposal to redesign the flow of throwing criminals in the brig and their subsequent release. Right now prisoners who aren't permabrigged usually have nothing to do during their sentence except hurry up and wait, and security officers usually have no reason to interact with the prisoner until their time is up and they need to be escorted out of security.
-
-## Current Brig Experience
-
-The current experience for brigging criminals looks something like this (your mileage may vary by map):
-
-1. Criminal is arrested by security officer.
-2. Criminal is brought to security and strip-searched.
-3. Depending on the severity, the criminal is thrown into either an individual brig cell for a few minutes (which is the case for most criminals) or into the permabrig area which (depending on the map) usually allows permabrigged prisoners to interact and/or do things like gardening.
-4. When a non-permabrigged prisoner's time is up, the cell door opens and they can collect their belongings, but they are still trapped in the security department due to airlock access until someone lets them out.
-
-## Turnstiles
-
-Turnstiles are a key feature in the new brig experience that I'm about to propose. Turnstiles are effectively one-way airlocks, allowing travel only in one direction while still allowing mappers or engineers to set normal airlock access requirements to move through them. Here's what they look like on Oracle, including the mapper overlay to show which direction players can move.
-
-![turnstile](https://i.imgur.com/QStUhoA.png)
-
-In this example a player with the relevant access requirements can only move from the north side to the south side of the turnstile. Even ignoring the rest of this design document, turnstiles would still be useful for things such as putting an exit in medbay or being able to leave the disposals room in maintenance.
-
-## Proposed Brig Experience - Genpop
-
-I propose that we completely nuke individual brig cells. All prisoners will now be thrown into a large secure area similar to the permabrig (called "genpop") where they can intermingle, kill eachother, or perform various other mapped-in activities like play arcade games or do basic botany.
-
-Here's an example from OracleStation. Note the turnstiles, the prisoner processing room in the lower part, and the actual genpop prisoner area in the upper part (ignore the armory in the bottom left):
-
-![genpop](https://user-images.githubusercontent.com/202160/35178888-91bb7eb6-fd87-11e7-9040-15a6ef93602c.png)
-
-I highly recommend taking a look at the [OracleStation pull request](https://github.com/OracleStation/OracleStation/pull/419) as it has gifs for most of the things I'm about to describe with words.
-
-This is what the new experience for brigging criminals would look like:
-
-1. Criminal is arrested by security officer.
-2. Criminal is brought to security and strip-searched.
-3. Criminal is given a prisoner ID with their name & the length of their sentence. This ID's access is required to pass through the "entrance" turnstile into genpop, to ensure the security officer processed them correctly.
-4. Criminal is thrown into genpop with all the other prisoners via the "entrance" turnstile, regardless of their crime severity. Individual brig cells and a separate permabrig no longer exist.
-5. The criminal's turnstile access is tied to their prisoner ID. Once their sentence has elapsed, they will now have access on their prisoner ID to pass through the "exit" turnstile from genpop back into the processing area. This means they can leave genpop with no intervention from security officers.
-6. The criminal can retrieve their possessions from the locker in processing using their prisoner ID.
-7. Using turnstiles, the criminal is able to exit genpop, processing, and the main security department entrance without needing a security officer to open doors for them.
-
-## Gameplay Implications
-
-Here's a non-exhaustive list of impacts these changes can have on gameplay, in no particular order:
-
-- Players no longer need help opening airlocks to exit security when their sentence elapses
-- Players now have things to do while they are brigged, whether it's ~~killing~~ interacting with other prisoners or the items/machines mapped in genpop
-- Players could escape early by stealing or trading eachother's prisoner IDs
-- Wardens are now incentivized to actually keep an eye on the brig and its prisoners to prevent fights/prison breaks/shenanigans
-- The brig effectively no longer has a prisoner capacity limit, as individual brig cells are no longer needed
-- Security officers can pass through genpop turnstiles at will with their ID access, allowing them to enter/exit genpop without prisoners tailing them to escape
-
diff --git a/src/en/proposals/ike709-robusthub.md b/src/en/proposals/ike709-robusthub.md
deleted file mode 100644
index cc585c027..000000000
--- a/src/en/proposals/ike709-robusthub.md
+++ /dev/null
@@ -1,110 +0,0 @@
-# RobustHub™
-
-| Designers | Implemented | GitHub Links |
-|---|---|---|
-| ike709 | :x: No | WYCI |
-
-## Overview
-
-Redesigning the launcher UI/UX and server hub concept to better facilitate creating and playing games developed in Robust Toolbox that *aren't* Space Station 14.
-
-#### This proposal is a high-level conceptual overview. Please do not bikeshed specific details such as every potential field for RobustHub metadata. Once this is conceptually approved, the bikeshedding can commence in subsequent design documents fleshing out each aspect of the design.
-
-Even the nomenclature used (e.g. "Game Hub") is subject to change but preferably won't be bikeshedded prior to overall proposal approval.
-
-## Games & Game Hubs
-
-### Defining "Game"
-In this context a "game" is referring to a single *project* such as Space Station 14, OpenDream, or RobustSand. Forks of SS14 are considered separate codebases, but still part of the SS14 "game".
-
-### Server Hubs
-The current concept of a hub is essentially just a list of servers. Under this new system these would effectively be the same, except now each server hub will be associated with one or more "games". These will be referred to explicitly as "Server Hubs" to distinguish them from "Game Hubs".
-
-Each Server Hub will have a whitelist of game(s) that can be advertised on it. For example, the official WizDen Server Hub could support both SS14 and RobustPong servers. When a server attempts to advertise on a Server Hub, it must declare the game that it is running and it must be one of the Server Hub's whitelisted games to advertise successfully. Server Hub operators are responsible for moderating the servers that are permitted to advertise on their hub, and ensuring that information such as the advertised game is accurate.
-
-When a player adds an additional Server Hub in the launcher, the additional servers will be associated with the correct games using the game identifier being advertised by the server. More on this later in the launcher section. A potential quality-of-life enhancement would be to allow players to toggle individual games on a per-Hub basis (e.g. if I were running my own alternative Server Hub for OpenDream servers dubbed "IkeHub", which advertises both SS13 and Eternia servers, a player may wish to disable polling the hub for Eternia servers if they only play SS13).
-
-### Game Hubs
-A higher-level hub dubbed "Game Hub" will fill a similar role to server hubs, but instead of providing a list of servers they will provide a list of *games* and their associated metadata that the launcher needs in order to play them and/or browse their Server Hub. **Note:** The launcher is only intended to support a singular "Game Hub", and the concept exists to provide examples of how Robust Toolbox can be utilized separately from Space Wizards Federation infrastructure, such as games developed independently of SS14 or communities who wish to "hard fork" their own infrastructure.
-
-The list of games available on a Game Hub is under the purview of the hub's operators. The official Robust Toolbox Game Hub (RobustHub) will be managed by the Space Wizards Federation. The system now looks something like this ([direct link](https://i.imgur.com/lyRfy8t.png)):
-
-
-
-### RobustHub Repository
-A new Space Wizards repo will be created called RobustHub (or similar). This repository will provide the "official" Game Hub that will easily be accessible with any official build of the launcher.
-
-Each game will have a directory in the repository with a variety of metadata and branding files (e.g. the game's default logo). I expect this will be fleshed out and bikeshedded more thoroughly in a separate design document, but metadata would consist of information such as:
-- Game name (obviously)
-- Creator/Developer information
-- Official Discord/GitHub/Website/etc.
-- URL to pull News from (like the existing News tab in the SS14 launcher currently)
-- If the game is singleplayer, multiplayer, or both.
- - Multiplayer games will include the default/official Server Hub URL for the game
- - Multiplayer games can decide whether or not to allow adding alternate unofficial hubs in the launcher (obviously SS14 would allow them, but Johnny GameDeveloper might want full control of the servers for his game)
- - Exclusively-singleplayer games will point to the content bundle download URL
- - (Side note: the existing SS14 launcher still can't launch singleplayer games you've already downloaded like RobustSand)
-
-Adding a game to RobustHub should be as straightforward as creating a pull request and meeting whatever criteria is deemed sufficient by the RT project managers to be considered a separate game.
-
-The process of who will be permitted to update a game's hub entry and how will be fleshed out in a future design document dedicated to RobustHub pending this proposal's approval.
-
-## Launcher Changes
-
- I couldn't find a way to articulate these launcher changes that doesn't make it sound a little crazy at first, so I advise reading all of this section before judging it.
-
-### Robust Launcher
-The SS14 launcher as it exists currently will no longer be maintained as a project. Instead the launcher will be stripped of all SS14 branding in favor of Robust Toolbox branding. The "Servers" tab will be nuked in favor of an interface similar to the BYOND pager, except with RobustHub games instead ([direct link](https://i.imgur.com/DSXdzyP.png)):
-
-
-
-I don't expect it to look exactly the same; for example, we may have a separate page for singleplayer games. But players will be able to download, play, or browse the server list for any RobustHub game from Robust Launcher.
-
-#### Adding Alternate Server Hubs
-As previously mentioned, the launcher will support allowing players to add additional Server Hubs. This should be as straightforward as adding a URL to a list in the launcher settings, with the launcher handling it from there. The launcher will check to make sure a game's RobustHub metadata permits alternate hubs before polling an alternate Server Hub for that particular game. When a player goes to a particular game's server list, the launcher will poll the Server Hub only for servers with that game's identifier. On the game's server list, each server entry will include a field displaying the Server Hub it was pulled from, and the list should support optionally filtering by Server Hub.
-
-Adding alternate Server Hubs should warn the player about potential moderation issues compared to using official Server Hubs. We may wish to somehow present each hub's rules to the player when the hub is being added in the launcher.
-
-#### Optional: Steam Release
-I'm of the opinion that Robust Toolbox should have its own dedicated Steam page which ships Robust Launcher directly, to reduce confusion when people want to play other RT projects like OpenDream via Steam. I'm not saying we should do this *immediately*, but I think it's worth serious consideration if any not-SS14-adjacent projects are created in Robust Toolbox.
-
-We should also check Steam's policy for this sort of thing, as the SS14 launcher at this point would just be Robust Launcher in Game-specific Mode for SS14 (see below).
-
-### Game-specific Mode
-Obviously we can't just switch out the SS14 launcher on Steam for Robust Launcher, which is where Game-specific Mode (better name pending) comes in. Somewhere in the launcher build pipeline we will need the option to pass in a RobustHub game identifier which tells the launcher to launch in Game-specific Mode for that game.
-
-When operating in this mode, the RobustHub page is not accessible by default, instead the launcher opens directly into the page for the specified game. This would look practically identical to the current SS14 Launcher experience.
-
-However, buried deep in the launcher settings would be a setting for "Other Games Browser" or similar, which gives the whole explanation that the launcher is able to play other games made in the same game engine. Enabling this setting would still keep the game in Game-specific Mode and open straight into SS14 by default, but now the "RobustHub" page (which would normally be the default page outside of Game Mode) will be unlocked as an additional tab that they can easily navigate to. The purpose of this is so users whom are aware of this functionality don't need to have a duplicate Robust Launcher installation on their PC.
-
-Let's expand upon the hub diagram to incorporate launcher examples ([direct link](https://i.imgur.com/Kz5KM6Y.png)):
-
-
-
-#### Optional: Don't Hide Other Games
-PJB seems amenable to the idea of _not_ hiding the Other Games list by default when operating in Game-specific Mode.
-
-### Example UX
-Here's the process of joining an OpenDream server depending on whether you're using Robust Launcher or the redesigned SS14 Launcher (which is just Robust Launcher in Game-specific Mode for SS14). This assumes we do decide to hide other games by default in Game-specific Mode.
-
-#### Robust Launcher
-1. Start Robust Launcher
-2. Find and select OpenDream from the list of games
-3. Pick a server and join it
-
-#### SS14 Launcher
-1. Start SS14 Launcher
-2. Go to somewhere deep in the launcher settings
-3. Enable the "Other Games Browser" setting (only needs to be done once)
-4. Exit the settings menu
-5. SS14's main page now has a "RobustHub" or "Other Games" tab in the corner that players can select
-6. Find and select OpenDream from the list of games
-7. Pick a server and join it
-
-Quality-of-life enhancements like being able to pin/favorite certain games is subject to further design and bikeshedding.
-
-### Optional: RobustHub Game Jam
-
-Once RobustHub is fully implemented, we should advertise and then run a game jam (1-2 weeks) to develop new games (singleplayer or multiplayer) for RobustHub, unrelated to SS14. In addition to adding some variety to the games list, this will give us a chance to dogfood the system and also identify pain points in creating new Robust Toolbox projects.
-
-Depending on the level of interest, we could potentially offer prizes for the best submissions like a fancy Discord role and/or a $20 Steam gift card.
diff --git a/src/en/proposals/ike709-statpanels.md b/src/en/proposals/ike709-statpanels.md
deleted file mode 100644
index 4b2692fc6..000000000
--- a/src/en/proposals/ike709-statpanels.md
+++ /dev/null
@@ -1,74 +0,0 @@
-# Diegetic Statpanels (aka PDA Statpanels)
-
-| Designers | Implemented | GitHub Links |
-|---|---|---|
-| ike709 | :x: No | WYCI |
-## Concept
-
-Taking all of the benefits of SS13 statpanels without ruining immersion nor reviving verb panels.
-### SS13 Statpanels
-
-Statpanels in SS13 generally serve one of three functions:
-
-1. The Status tab informs players with a round timer, station clock, escape shuttle status, etc.
-2. Debug-related info tabs like the Master Controller tab.
-3. Verb tabs like IC or OOC which are just lists of verbs the player can run.
-
-The second item is unrelated to the average player. The third item is, frankly, terrible UX.
-
-This design document is focused on the first item: the Status tab. I believe that certain basic information should be conveyed to the player *almost* always. This includes most of the information conveyed by the SS13 Status statpanel as previously mentioned: round timer, current map, station time, etc.
-
-The problem with the Status tab in SS13 is that, frankly, it's ugly and it ruins immersion. It's particularly bad on codebases that just use the default BYOND statpanels instead of replacing them with TGUI. So how can SS14 do it better?
-## SS14 Statpanels
-
-It's simple. SS14 already has a mechanic that conveys all of this information: PDAs. All we need to do is open the PDA UI in the statpanel location when a PDA is equipped in the PDA slot.
-
-Now in no particular order I'm going to address various considerations (many optional) involving mechanics, features, balancing, etc. all subject to player and maintainer input.
-
-### What if I lose my PDA?
-
-This should hide the UI, naturally. But replacing a PDA should be made trivial. PDA vendors should be added to areas such as Arrivals and Dorms that can supply people with simple, no-program unpainted PDAs if theirs is ever lost or stolen.
-
-### What if I don't want to use the PDA programs in the HUD's corner?
-
-Moving the PDA from the PDA slot to in-hand should move the UI from the corner to the center of the screen, and then put it back in the corner when the PDA is put back in the PDA slot.
-
-### What if I don't want to see this UI at all?
-
-Like in SS13, we could simply allow people to resize chat and shrink the statpanel by dragging the splitter upwards.
-
-### Isn't constant access to Programs a bit overpowered?
-
-I personally think this is a non-issue since you can't interact with the game window and PDA window simultaneously, but I can see how others would disagree so I came up with some potential solutions anyways. These are all optional and in no particular order:
-
-- **Lockscreen** -
- The PDA is "locked" by default, and the lockscreen is simply the Home tab. To access Programs, the player must do something such as:
- - Wait for arbitrary short doafter to represent typing in a passcode or biometric scanning
- - Actually needing to know and enter a 4-character PIN code each time it locks (it locks after brief periods of inactivity)
-- **Require In-Hand** -
- Require having the PDA in the player's active hand to use programs. This is my least favorite option.
-- **Require Empty Hand** -
- Require the player's active hand to be empty if they want to interact with programs. Just give them a popup text if they try to click programs with something in their hand.
-
-### Optional: Admin Tabs/Programs
-
-Add support for tabs and/or programs that are tied to the player's mind (or something) rather than the actual PDA. This would make it easy to support admin tools like a server performance monitor, a tab listing the gamemode and all antags, etc.
-
-### Optional: Map Tab
-
-My biggest complaint with the maps that aren't ripped straight from SS13 is that I have no idea where I'm going. Map terminals are great when I come across them, but I think having the ability to constantly have a map of the station would be a huge quality-of-life improvement for new players. Nothing stops them from just opening up a screenshot of the map in their browser anyways.
-
-### Optional: Diegetic Game Settings
-
-This is one of the spicier ideas, but out-of-character menus like the guidebook or the game's audio settings could be moved to a PDA tab. A big problem is that we'd need an elegant way to make sure the player can still access these if they lose their PDA.
-
-## UI Mockup
-
-Just remove the close button from the top right, maybe tweak the border a bit. It'd also need to stay there all the time when a PDA is equipped. Here's a pic ([direct link](https://i.imgur.com/ppnXXaf.png))
-
-
-
-## tl;dr
-([Direct image link](https://i.imgur.com/ByUHHZu.png))
-
-
diff --git a/src/en/proposals/julian-vasilis-pda-messaging.md b/src/en/proposals/julian-vasilis-pda-messaging.md
deleted file mode 100644
index a0fc4d34d..000000000
--- a/src/en/proposals/julian-vasilis-pda-messaging.md
+++ /dev/null
@@ -1,111 +0,0 @@
-## PDA Messaging
-
-| Designers | Implemented | GitHub Links |
-|---|---|---|
-| Julian & VasilisThePikachu | :x: No | TBD |
-
-*(Taken by [Julian doc](https://hackmd.io/iu2yK9bcQb-veuCOLl-FYw?both#Optional-Channels-and-Department-based-Channels) in hackmd and modified a lil. Mostly replacing "email" to "message", "Email address" to "user/user id" and adding some of my own twists. Julian was fine with this if i understood correctly (i was in vc with em))*
-
-*(This is mostly taken from how PDA messages work in ss13)*
-Allows sending messages to others using PDAs
-
-### What this adds and why
-Simple, Messaging via the PDA!
-Messaging someone via the PDA should be made when you need to get the attention of a special someone. Example as HoS you want to ask detective to come over to investigate an item. It's easier to get their attention cause of their PDA vibrating then hoping they are monitoring their channel. Another usage is the heads planning Captain a suprise birthday party. Something like that would require all heads getting together in one place.
-
-This is **not** a replacement to the radio channel. Theres no "common" channel, it would be easier to spoof being someone (just need their id), past messages on that same id can easily be exposed and its far more cumbersome to message someone over PDA then just using the radio.
-
-### Message storage
-Messages are stored on a server most likely will be stored in telecoms. There can be one server per station, others on the same station won't be used unless the first one loses power or gets destroyed.
-
-*Optional* The active server synchronises itself with all of the inactive servers on the same station (This happens inside the system directly, no device networking here).
-
-### One active / Multiple inactive server model
-
-(This talks about some refactor stuff and Julian told me they forgot to paste the link, im keeping it to be safe in case its actually useful.)
-
-The one active / multiple inactive server model uses the system that will get refactored into its own system from the crew monitoring server [link text]()
-
-The messaging client system will use the `GetActiveServer` method of the message server system to retrieve the active server if the client doesn't have a server set yet or that server timed out. *This is also from the system that gets refactored out.*
-
-### Sending and receiving messages
-
-When sending a message to someone via the program the PDA sends the message together with an 'user id' to the server and the server will send the message to the target device. Of course there will be a character limit (say... 100 characters?)
-
-When a PDA recieves a message it plays the PDAs ringtone and vibrates, showing the sent message on the chat. This message can also be viewed on the PDA via a program.
-
-Notifications can be disabled if desired.
-
-This user id could be generated into the ID card so that if you get a new PDA your messages are kept as long as you are using the same ID card. Late joiners will get assigned a uid when they arrive on the station. Potencially HoP or RD can move your UID to the a new ID card with the ID comnputer rendering the old ID card useless. This can also prevent powergaming by someone changing their UID to see others messages.
-
-This UID will receive messages for as long as it is in the station and in a PDA.
-
-If its not in station the messages can either fail to send or be added in a queue to be sent when it reenters the station.
-
-Since the UID is stored on the ID. That means that if you manage to get your hands on someones ID you can chat as them and potencially (if added) read their messages.
-
-### Users list
-
-When opening the PDA messaging app, you will be able to start a chat session with everyone connected to the server (aka everyone with a PDA)
-
-They will be listed by name and job title like this "Vapor-Tail (Captain)"
-
-*Optional* Add the ability for people to not be allowed to initiate a conversation with an option. This can be useful for high command staff like captain from getting message spammed by clown and others at the start of the shift.
-
-### Optional: Detomatix PDA Cartridge
-
-(find the original item in the tg wiki here: https://tgstation13.org/wiki/Syndicate_Items)
-
-The detomatrix is... a zip bomb in easy to say terms. Allowing you to send a spoofed message that when opened by the target fast enough bricking the PDA and its ID (instead of exploding... even though thats funnier maintainers please allow this)
-
-It will have a chance to fail and have an even lower chance of working on "high profile" PDA's like the Captains.
-
-It could be used as a way to get people to turn off their messanger function in fear to not being up next if someone screams in radio about it and could be useful.
-
-### Optional: Multiple network support
-
-The server is able send on the wireless and the wired network because it saves what network the registered devices are on along with the user id and the network address.
-
-This requires devices to be able to register themselves with two device net ids at once (which should only be done if it is really needed).
-
-### Optional: Channels and Department based Channels
-Channels are special groups that relay the messages sent to them to users who are subscribed to that channel.
-
-Channels can be created and they can be deleted by the channel creator.
-
-When registering to a server the client also sends the job of the inserted ID so the server can put them into special department channels.
-
-Department channels can't be joined, left or deleted.
-
-### Optional: RDs messager admin management console
-The research director and potencially Captain get a console which connects to the message server via device net that can be used to view and manage all messages and groups.
-It uses device net with an `AccessComponent` on the message server so the management functions can be hijacked by traitors that got their hands on an ID card with the right access. (This requires [device net access restrictions](https://hackmd.io/gPjP95_zRUiT-bX4hKxE6w) to be implemented.
-
-### Optional: pAI as a chat assistant.
-This will add new gameplay for the pAI ghost role. Allowing the pAI to chat as their master on their behalf. Could have a little pAI icon in the chatbox to show it was sent by the pAI and not the actual player. pAI's for a while have been kinda boring and may deserve their own design doc of ideas but this is one of my ideas that come to mind.
-
-
-### Concerns
-When initially asked about this I was met with some concerns. This section is to address them
-
-Discord discussion start: https://discord.com/channels/310555209753690112/310555209753690112/1160244698112327830
-
-##### Why PDA messaging over plain radio? Would this upset radio balance and reduce coms over radio?
-First of all why:
-If you play the game you can quickly realise how getting someone's attention god forbid multiple, can be... not an easy task to say the least. You either are lucky and the person you want is just so happening to be monitoring the chatbox or they are busy and not paying attention. In the end missing your message until you resend it or try to look with them. This is just not fun and is just annoying. PDA messaging can solve this.
-
-As to if it will upset radio balance: Highly unlikely it will be. Mostly cause:
-1. PDA messaging wont let you get the attention of multiple people at once (common). PDA messaging can reach one person at the time (unless we get department groups but even then). You will have to jump through a lot of hoops if you JUST wanna use messaging. Radio is easier and faster to talk into and gets to multiple people at once.
-2. Sending a PDA message is more of a chore then just using the radio channel, PDA messaging will at least need a minimum of 6 steps to open the PDA, go to the app section, start the app, find the person, write the message and send. And if you keep the chatbox on it would just take up a good chunk of your screen. Or you could just do ":c Captain hamlet ate uranium"
-3. Messages are stored and logged. Someone steals caps PDA? Well now all of their messages are up on display. With radio unless they had command channel already they would never learn of any past messages. If two syndies decide to use PDA messaging rd can just grab their chatlogs. Same with syndies using it to communite with others.
-4. PDA messaging has a pretty small character limit, if you wanna say something long radio is the place.
-
-May be the wrong section but admins can also use this to act as "Central Command" so instead of having to subtile message someone they can just send a message to their PDA.
-
-##### It reduces everyone else's situational awareness since people can't see all radio messages anymore.
-I highly disagree, I doupt it will reduce situational awareness more then it already is. I have already went over how someone monitoring the radio channel for messages directed to them is already a chore. PDA messaging names can easily be changed by using someone elses ID therefore its a good idea to not go to maints like they told you to and instead show the message to security.
-
-##### Why not use fax?
-Is this really a question? First of all not everyone has a fax, second you have to be close to hear it go off printing. And unless you check your fax periodicly for new faxes messages can be missed. And even if you do check it its probably boykisser ASCII spammed 10 times. Also why are we using *faxes* in 2563 or whatever year SS14 takes year in.
-
-These were all the conserns I could find from discord.
diff --git a/src/en/proposals/mirrorcult-anomaly-cores.md b/src/en/proposals/mirrorcult-anomaly-cores.md
deleted file mode 100644
index 86e115be6..000000000
--- a/src/en/proposals/mirrorcult-anomaly-cores.md
+++ /dev/null
@@ -1,49 +0,0 @@
-# Anomaly Cores and the G.O.R.I.L.L.A Gauntlets
-
-| Designers | Implemented | GitHub Links |
-|---|---|---|
-| mirrorcult | :white_check_mark: Yes | https://github.com/space-wizards/space-station-14/pull/21306 https://github.com/space-wizards/space-station-14/pull/23012 |
-
-The intention of this proposal is not to expand the anomaly gameplay system through breadth (i.e. more stuff) but to add new dimensions of gameplay and new incentives entirely. This will be done through two main additions: **inert & decaying anomaly cores**, and the **G.O.R.I.L.L.A Gauntlets**.
-
-## Anomaly Cores
-
-
-
-**Anomaly cores** are generated when an anomaly dissipates in some way. An *inert* core is spawned when an anomaly is fully contained and fizzles out, and a *decaying* core is spawned when an anomaly goes supercritical.
-
-Inert cores are functionally useless on their own, sell for a small amount of money, and glow faintly. They become useful in conjunction with the G.O.R.I.L.L.A, which will be elaborated on later. They can also be made into anomaly core pie!
-
-**Decaying cores** are the interesting ones. When an anomaly goes supercritical, it will spawn a decaying anomaly core of the same type as the anomaly. These cores can be sold for a large sum of money, converted into a fairly high amount of research points, or *used by anyone for a one-time anomaly-specific benefit* (this use will not be included in the initial PR for scope reasons).
-
-Over time, decaying anomaly cores will slowly *lose their value* and eventually convert into an inert anomaly core. If it isn't sold, exchanged, or used fast, then the whole endeavor could prove pointless.
-
-### Intended Gameplay
-
-The point of decaying anomaly cores being generated is twofold: First, it provides a potential benefit for anomalies which accidentally go supercritical or are untended to. Second, it gives anomalists the interesting choice to **intentionally make an anomaly go supercritical** for huge rewards, if they feel that they're capable of handling the aftermath.
-
-Decaying anomaly cores being time-limited is very important. This introduces more gameplay by forcing people to take some risks to extract as much value as possible. For instance, you might just run into a supercritted gravitational anomaly to take its core even if you risk harming yourself. It also forces the decision of *how* to use the anomaly core quickly, which can lead to some fun social scenarios.
-
-## The G.O.R.I.L.L.A Gauntlets
-
-```admonish info
-or, Gauntlets Orchestrating Relocation of Interloping and Ludicrously Livid Anomalies
-```
-
-
-
-The G.O.R.I.L.L.A Gauntlets are an item obtainable through Tier 2 experimental research (subject to change). It functions as a set of wieldable power fists that can deal strong brute damage. However, they're not very strong on their own. To take full effect, they need to be **with an anomaly core**.
-
-When the gauntlets are loaded with either type of anomaly core, they gain the ability to force throw anything they hit backwards, until it hits a wall. **This includes anomalies, and thus the gauntlets function as a method of moving anomalies.** Inert cores only give you five charges to work with (subject to change), while decaying cores will work until they run out, and deal significantly more damage.
-
-Anomalies which are hit with the gauntlets will take some minor stability damage. Anomalies in the process of going supercritical can also be hit with the gauntlets. Because of the nature of how the force throw works and the limited charges of an inert core, anomalists will have to first consider the most efficient path and set of pushes to get the anomaly in a more useful location.
-
-### Intended Gameplay
-
-The G.O.R.I.L.L.A gauntlets open up many more choices for anomalists. Before, if an anomaly spawned in a particularly unfavorable spot (such as medbay), science was heavily pressured to contain and decay it entirely rather than trying to exploit it, and for good reason. People have often asked for a way to move anomalies, but of course, anomalies' locations being random is a huge part of what makes them interesting to contain.
-
-With the G.O.R.I.L.L.A gauntlets, anomalists have a way to move unwieldy anomalies in an interesting way that generates rather than removes gameplay:
-- The gauntlets require an inert core and research, so science must already have invested some time into anomalies already
-- The inert cores have finite charges, so science cannot always rely on them
-- The movement of the anomaly is not as simple as 'point A to point B', and because of the limited charges, scientists must consider the location of the anomaly and where they'll be able to move it within 5 pushes, kind of like a box-pushing game or a Pokemon ice tile puzzle, which is a fun mini-challenge on its own.
-- Expert anomalists will be able to modify the environment to get anomalies in even more favorable locations and they will likely have to coordinate with others to move it through doors, hallways, into smaller rooms, etc, introducing a new degree skill expression, on top of knowing when to make the decision to try and move one rather than contain or harness it.
diff --git a/src/en/proposals/mirrorcult-cleanup-crew-gamemode.md b/src/en/proposals/mirrorcult-cleanup-crew-gamemode.md
deleted file mode 100644
index 97261fcba..000000000
--- a/src/en/proposals/mirrorcult-cleanup-crew-gamemode.md
+++ /dev/null
@@ -1,53 +0,0 @@
-# Cleanup Crew
-
-| Designers | Implemented | GitHub Links |
-|---|---|---|
-| mirrorcult | :x: No | TBD |
-
-## Overview
-
-Cleanup Crew is a lowpop (0-20 players) gamemode built around the concept of repairing destroyed stations from previous rounds. The goal is to provide a fun, relatively chill experience that differs from the base game but still interacts with all of its systems (especially construction, power, atmos, etc), acting as an educational experience, while also being very atmospheric.
-
-The NanoTrasen Emergency Cleanup Crew, one spacemonth after the sudden abandonment of their finest new station, will start the game on a medium-large ERT shuttle near the disheveled station. The shuttle is stocked with everything you could need--lots of materials & RCDs, medical supplies, atmospheric supplies, generators, janitorial equipment, etc.
-
-Each cleanup crew member has a designated role (atmospherics, power, repair, janitorial, security, etc) but they can of course branch into doing anything as needed with their supplies. The goal of the cleanup crew is to ensure:
-
-- the station's tilemap is as close to the original station's tilemap as possible
-- as many of the original tiles have viable air as possible
-- the new station has as many of the same machines as the old station, and that as many of them are powered as possible
-- as few spills, blood & dirt remain as possible
-- as many "intruders" are eliminated as possible
-
-The cleanup crew is given a time limit of 1-3 hours (depending on how large the map is & its chaos value), after which they must FTL away inconspicuously to evade detection by the Syndicate.
-
-## Intruders
-
-As mentioned before, the map is mostly kept unchanged from the saved version, but it *has* been a whole spacemonth!
-
-It's possible that some hostile fauna (and some decorative flora for that rundown feel) have moved in. These can include:
-
-- Xenos, which will have spawned resin walls and eggs randomly
-- Spiders, which will have spun lots of webs and nests
-- Carp & sharks, which will be scattered around the station with a dragon or two sprinkled around
-- Orecrabs, with corresponding rock deposits that must be cleared out
-- Nothing! No one got there before you did. A chill experience
-
-Only one class of intruders is selected for the whole station, and they (along with any infrastructure they bring with them) are procedurally dotted around the station in clusters or in singular surprise instances.
-
-The cleanup crew comes loaded with plenty of medical supplies and !!FUN!! pulse & powerful ballistic weaponry, so these aren't generally much of a real threat, but they do make for a more dynamic experience.
-
-## Scoring
-
-The cleanup crew, at the end of the round, is scored based on the factors mentioned above. The score is compared to how the original station would have scored, and some flavor text is displayed congratulating or disparaging the cleanup crew on their hard work.
-
-## Map Saving Mechanic
-
-To elaborate on how the maps are selected:
-
-After any round finishes on some server, a quick heuristic "chaos value" (power, atmos, tiles missing) is calculated to evaluate how "destroyed" a station is. If the chaos value is high enough (but below a certain critical threshold of too much destruction), the map is saved, with some annoying entities removed (all mobs are replaced with skeletons, for example), and then stored as a blob in the DB to be used later.
-
-Up to ~20 (maybe less, maybe more) stations can be saved at a time, and when a cleanup crew gamemode spawns, one is removed from the list and loaded in. If a map cannot be loaded, another is tried, until there are none left in the list. If there are no viable maps for cleanup, the gamemode is unavailable for play.
-
-After the map is loaded, a short procedural pass spawning random mess decals and flora such as trees and bushes or vines is done. Afterwards, if an intruder (see above) was selected, they are spawned in as well.
-
-Some scenarios, like a nuke going off after nukies, will mark the map as unable to be saved for cleanup crew, since it's obviously a bit too much of an outlier.
\ No newline at end of file
diff --git a/src/en/proposals/mirrorcult-rogue-drones.md b/src/en/proposals/mirrorcult-rogue-drones.md
deleted file mode 100644
index 4e74cdd99..000000000
--- a/src/en/proposals/mirrorcult-rogue-drones.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# Rogue Drones
-
-| Designers | Implemented | GitHub Links |
-|---|---|---|
-| mirrorcult | :x: No | TBD |
-
-
-
-## Background
-
-rogue drones is kind of a placeholder name its not that good we can come up with something better or just call them swarmers who caaaaares
-
----
-
-On some SS13 servers, an antagonist called the **swarmer** exists (or existed, as it was disabled in some places). It's goal was to destroy machines & structure around the station and convert it into material to create more swarmers with. Essentially grey goo. They had extremely limited combat capabilities (mostly traps & stuns) and are generally hated for being extremely annoying, disruptive, and overly centralizing.
-
-**Drones** also exist on some SS13 servers, and even on SS14 for a time (disabled for being too much of an admin burden). They're not antagonists, and are intended to just be a little ghostrole that tries to repair the station and keep itself out of the way of the crew. Because of this, they end up being weirdly restrictive and almost like a separate part of the round entirely since they're forced to not interact with anyone.
-
-This concept seeks to unify the two and solve the issues of both while creating an interesting grey-morality antagonist at the same time.
-
-## Overview
-
-**Rogue drones** are a mid-round ghostrole antagonist that can spawn in maintenance.
-
-They're space-capable silicons and quite fast, along with the ability to sneak under airlocks like mice, but have zero combat prowess and little bulk. They also can't interact with machines or speak, but can use the binary channel of the station to communicate with eachother. They come with a set of unremoveable tools that are quite powerful, as well as slots for metal and glass they can use to build structures. Using a decent bit of steel and wires, rogue drones can create another shell that can be inhabited and multiply, though they'll usually prefer to use that material to expand.
-
-Their goal is well-defined and is simply to **increase the number of tiles on the station with habitable air by any means necessary**. This implies a couple things. Rogue drones:
-- are incentivized to deconstruct walls and doors both to get materials and to create new openings for air, but they don't particularly care about touching structures or anything else useful. They're also willing to steal metal and glass directly if they find it lying around.
-- goals sometimes align with the crew and are thus somewhat often **actually useful to the station**, as they're quite willing to fix hull breaches and tackle atmospheric issues.
-- will often try to build useless rooms or expansions to the station, coordinating amongst themselves to store materials and collaborate, while negotiating with other silicons (who are also on their channel!)
-
-The intended effects here are quite obvious but I will list them regardless:
-- The crew, and individual crewmembers, have the interesting choice to think about ignoring or temporarily allowing the rogue drones to roam freely because of their aligned goals.
-- Rogue drones serve the function that previous maintenance drones did--allowing players to get back into the round and learn or have fun with construction mechanics--while sidestepping the admin burden, since they're antagonists with limited capabilities.
-- Rogue drones have a lot of the same gameplay as swarmers did--multiply, try to deconstruct and build new things, run from the crew--while not being overly annoying since they have negative incentives with regards to spacing areas or deconstructing machines, as well as not having any combat capability.
-- With a clearly defined numerical goal, players feel motivated to have fun and actually perform their task and see the fruits of their efforts rather than just fuck off and do nothing
-- A non-combat-focussed antagonist fills out the midrounds with some more actual variety in how players interact with them and makes everything more interesting
-
-## Other Mechanics
-
-At the end of the round (and periodically in the objectives screen), the game will calculate how many tiles of the station have habitable air, compare it to the station start amount, and award greentext based on that.
-
-Rogue drones have a silicon lawset that guides their goals. The lawset is as follows:
-
-```
- 1. You must maximise the amount of tiles with breathable air.
- 2. A tile with breathable air must have at least 20mol of oxygen and 20mol of nitrogen.
- 3. A tile with breathable air must be between 60kPa and 200kPa of pressure.
- 4. A tile with breathable air must be between 283K and 303K of temperature.
- 5. A tile with breathable air must have below 0.1mol of gases dangerous to living creatures.
-```
-
-Rogue drones are subject to ion storm events the same as other silicons, so its possible for their laws and thus goals as antagonists to be changed dramatically! How fun.
-
-Rogue drones have an innate air alarm tuned to the settings listed in their laws which makes it easy to check whether a given room meets the guidelines.
-
-On a cooldown, rogue drones can use their built-in recyclers to spew out a certain amount of air to help with refueling rooms.
-
-## Lore
-
-Obviously not as important but the idea is something as follows:
-
-Engineering drones are legacy NanoTrasen tech that was delivered to a few stations but rarely ever succeeded, so were generally phased out. Occasionally, a drone's decaying chassis, left in old maintenance tunnels, experiences a surge, powers back on and starts following its directives once again. Unfortunately, the legacy robotics department at NanoTrasen didn't care much for safety, so their laws leave a lot of room for incentivizing bad behavior--the decision to allow them to replicate wasn't so wise either.
-
-### Possible future ideas
-
-- Maybe a special RCD that can't deconstruct floors but can "eat" metal/glass to turn into ammo?
-- Another way of creating rogue drone shells that is less swarmer-like?
\ No newline at end of file
diff --git a/src/en/proposals/notafet-atmos.md b/src/en/proposals/notafet-atmos.md
deleted file mode 100644
index 1f3b2f870..000000000
--- a/src/en/proposals/notafet-atmos.md
+++ /dev/null
@@ -1,117 +0,0 @@
-# Atmos Roadmap
-
-| Designers | Implemented | GitHub Links |
-|---|---|---|
-| notafet | :warning: Partially | https://github.com/space-wizards/space-station-14/pull/21954 https://github.com/space-wizards/space-station-14/pull/22358 https://github.com/space-wizards/space-station-14/pull/22468 |
-
-## Background
-
-Most atmos players currently agree that atmos is not very fun to play, for some of the following reasons:
-
-1. There is little content to play after round-start setup. Part of the problem is that things like distro and TEG are "set up and forget".
-
-2. Atmos can't actually rectify atmos problems in a reasonable amount of time. For example, if there actually is a plasma leak, scrubbers typically work too slowly resulting in the plasma inevitably being lit before it can be cleaned up.
-
-3. Atmos techs don't play with the rest of the station, preferring to isolate themselves to produce a funny green gas that is only particularly useful for shuttle bombing. Mechanics like this violate the [fundamental design principles](../space-station-14/design.md). While these mechanics shouldn't be removed per-se, more focus should be given to mechanics that increase interactions with the station, like making sure the air is breathable and well-heated.
-
-## Proposal
-
-Make atmos more fun and intuitive to play by adding more devices, engines, and processes inspired by SS13 and/or quasi-realism.
-
-**An atmos tech's primary job is to keep the station livable and breathable.** There are a lot of interesting real life challenges associated with making this happen, not in the least of which is that in space, every gas molecule wants desperately to escape into the cold of space. There is also the challenge of keeping the station appropriately temperature-regulated despite the cold outside and occasional plasma fires inside. There is the opportunity to create a lot of game play by recovering from a breach or a station fire.
-
-## Core Changes
-
-Using just the devices that already exist, there are some tweaks that can significantly improve gameplay in atmos by making it possible to effectively respond to events like fires or hull breaches.
-
-- ~~**Globally increase MaxTransferRate** for devices that are not flow-based, e.g. pumps.~~ (implemented in [atmos speedup](https://github.com/space-wizards/space-station-14/pull/22372))
-
- - This solves problem (2). Among other things, it would make scrubbers and other devices actually useful for combating atmospheric problems. Currently players prefer to just space everything. Increasing this would provide a feasible alternative.
-
-### Device Design Principles
-
-Atmos devices should behave intuitively, as one might expect them to behave coming from real life experiences. This means that player should not need to care, or even be aware, about internal abstractions like the "pipe net". Devices should follow the basic principles that:
-
-1. Energy and matter should be neither created nor destroyed.
-2. Gas flows from high pressure to low pressure unless forced by a pump.
-3. Temperature transfers from hot to cold. Going the opposite direction requires energy input.
-
-These principles suggest changes to devices:
-
-- Instead of having hard transfer rate limits, **scale transfer based on pressure differences.** This means driving gas flow as a result of pressure differences created using pumps external to the device.
-
- - This addresses an important issue concerning atmos intuition and accessibility. Players should not have to understand the internal workings of the pipe net system (e.g. a pipe is one big node, gases move between them). In real life, a fan or pump creates a pressure difference, and pressure differences drive gas flow. If someone blows on one end of a straw, they can expect it to come out of the other end, not get stuck in the middle of a pipe net.
-
-- **Add soft clogging (aka pump efficiency curves).** Right now if you have two pumps in series, it is possible for the middle node to appear to be at 0 kPa because the second pump is faster. This leads to confusion and inaccessibility. When pumps get clogged, they also get "hard" clogged which means that they stop pumping altogether.
-
- - This lets us finally differentiate pressure and volume pumps. Pressure pumps are good at moving smaller quantities of gas across large pressure differentials, while volume pumps are better at moving more volume across smaller pressure differentials.
-
- - This also improves problem (2) by uncapping transfer rate.
-
-- **Make heaters and freezers binary.** Just like how central heating and air conditioning circulate air through heat/cold coils, gases should flow across heaters and freezers in order to exchange temperature.
-
- - Heaters and freezers are the only "true" unary devices. Even vents/scrubbers which appear unary actually operate on flow from the tile atmosphere into the pipe net.
-
-- ~~**Make heaters and freezers thermodynamically sound.** Keeping a station properly heated or cooled is actually a substantial real-life problem. Because of the existence of generators like the TEG, keeping things thermodynamically balanced is also a great way to prevent infinite power hacks.~~ (implemented as a part of [atmos speedup](https://github.com/space-wizards/space-station-14/pull/22372))
-
-## New Stuff
-
-This list isn't meant to be exhaustive. Some of the ideas discussed here aren't fully fleshed out. Some of these call for porting mechanics from SS13 with changes as needed/appropriate.
-
-- **A "substation" but for gas,** "gas manifold", distribution station, or whatever you want to call it. This would encourage distro to be at high pressure (for higher transfer rates) but then gas distribution stations scattered around the station would bring it down to a normal pressure that is released to vents. Adds antag complexity and gives atmos techs more control.
-
-- ~~**Add gas condensation.** This would enable fractional distillation and permit conversion between gas and the equivalent reagent.~~ (implemented in [#22436](https://github.com/space-wizards/space-station-14/pull/22436))
-
-- ~~**Space heaters** to correct local temperature problems.~~ (implemented in [#25250](https://github.com/space-wizards/space-station-14/pull/25250))
-
-- **Make station air flow-based.** Currently, air vents release air when the pressure is too low, and by default scrubbers only scrub waste gases. So if for some reason the station gets cold, there's no easy way to cycle the air out and heat it up. Of course, one could set all the scrubbers to siphon, heat their distro, and then set the air alarm to fill. But that would just be describing a bad way of doing what real life HVAC systems have always been doing: keep the air flowing.
-
- - This addresses problem (2) by making it possible to better regulate station temperature.
-
-- **Adding process-based alternatives to scrubbers and filters.** This calls for adding more gases and gas reactions. For example, with gas reaction-based scrubbing processes, scrubbers with limited uses, or physical processes.
-
- - This addresses problems (1) and (3) by adding more content that is directly related to the well-being of the station.
-
- - One of the most pressing challenges in the real world is "how does one separate different kinds of gas." Most current methods of gas extraction are based on chemistry (e.g. real life carbon dioxide scrubbers contain chemicals that react with CO2, pulling it out) or physical methods (e.g. fractional distillation, where one cools down air in different stages to get liquid nitrogen, oxygen, etc.) This creates a lot of opportunity for new game play mechanics and industrial processes. This would also give more opportunities to add gas-based reactions (i.e. more content).
-
- - This does not advocate for removal of scrubbers and filters, but rather makes it a mapper option, e.g. whether to use scrubbers at round-start or make atmos set up a system depending on the desired level of role-play.
-
- - When set up correctly, these should have much higher processing rates than scrubbers. This should give an incentive to set these up, e.g. on longer rounds, while still keeping scrubbers as an option.
-
- - This adds "optimization, tinkering, and creation of intricate builds."
-
-- **Various QoL improvements** such as the RPD.
-
-- **More engines**, but the specifics are left out of here to be their own design doc proposals.
-
-## Wishlist
-
-These proposals are for the long term future. Some of them require other proposals, e.g. to reduce the dependence on research/cargo, before they should be implemented.
-
-- **Phase out gas miners for all upstream maps.** It doesn't make sense that all stations have free and plentiful sources of gas, otherwise this might as well be on a planet. This is a game that is literally set in space. It would make sense to keep a few specialty miners, e.g. for plasma, if a station is set on a plasma mining planet. But in general, all other gases should be imported via gas canisters. Miners should still be kept available for any forks that choose to use them.
-
- - This solves problems (1) and (3). Maintaining a livable atmos would involve work during the round beyond setting up distro to pipe gas from miners. It would help increase interactions with other departments, such as cargo and salvage as atmos needs to order gas.
-
- - Ensuring a appropriate round-start supply of gas would make the game playable without a functional cargo department.
-
- - This would discourage fighting fires or atmos problems by wholesale spacing a section. There is currently very little downside to spacing a section to get rid of problems because of an unlimited gas supply.
-
- - There is [overwhelming consensus on mappers for this](https://discord.com/channels/310555209753690112/770682801607278632/1162179968915210280).
-
- - As an interim or for very low pop-count maps, keep miners but make them mine gas at low temperature that has to be heated up before use. This preserves a bit of an incentive for atmos players to not space a section at the first sign of trouble.
-
-- **Add maximum temperature and pressure limits for most devices** such as pipes and canisters. It does not make sense that one can contain the surface of the sun in their pipes. Adding limits would encourage designing processes and systems that work within reasonable constraints.
-
- - Some "sub-optimal" setups are really unintuitive and wouldn't work in real life due to temperature and pressure limits.
-
- - There are some concerns about being able to run burn chambers and the TEG. The screenshot below demonstrates a TEG that is capable of powering an entire large-sized station (256.8 kW current output, the peak output is quite a bit higher) with a maximum pressure excursion of 1600 kPa. It shows that pipes that burst at reasonable pressures are entirely consistent with having burn chambers. This just needs to be set up correctly.
-
- ![image](https://user-images.githubusercontent.com/3229565/274441724-712f4ebf-7440-4d81-879e-19aa29788822.png)
-
- - This addresses problem (1), the "set up and forget" issue by adding temperatures and pressures to monitor. It also allows the opportunity for sabatoge.
-
- - This prevents somebody from doing a fusion burn inside a pipe.
-
- - This would need a station map pipe monitor similar to the new power map.
-
-- **Breaking windows at high enough tile pressure differences.** To handle explosions and resulting space wind without leaning on the explosion system, and to encourage people to design burn chambers with more controlled burns instead of always putting their pedal to the metal.
diff --git a/src/en/proposals/tday93-power-generation.md b/src/en/proposals/tday93-power-generation.md
deleted file mode 100644
index 70fdcd15d..000000000
--- a/src/en/proposals/tday93-power-generation.md
+++ /dev/null
@@ -1,127 +0,0 @@
-# A Core Pattern for Power Generation
-
-| Designers | Implemented | GitHub Links |
-|---|---|---|
-| tday93 | :x: No | TBD |
-
-## Background
-
-Power generation is currently in an odd state. In order to power the station suffciently at round start, engineers need to do one of the following:
-
-1. Collect a number of draggable generators, move them in to place and power them.
-2. Rush to cargo before the power goes out to order AME fuel.
-3. Rush the power source that can sustain the full round - A Singularity, a Tesla, or the TEG.
-
-In most rounds engineers will choose option number three. If they are relatively new, and take longer than the current
-short time window they have on the power the station started, the station is plunged into darkness and they are harassed
-on the radio. If they are very experienced, but want to take the time to teach new players to set up the power source,
-the station is plunged in to darkness and they are harassed on the radio. The only situation in which engineering is not
-harassed on the radio is an experienced engineer quickly setting up the power source in silence.
-
-This is not fun for the experienced engineer, the technical assistant trying to learn, or the other players stuck in
-darkness.
-
-This proposal will outline a generic pattern for power generation design which will seek to alleviate these issues, and
-simultaneously present engineer players with a wider variety of options for mid-round and end-round play.
-
-## Overview
-
-The proposed pattern for power generation is as follows:
-
-1. Round start power stored in station batteries that without intervention rapidly deplete - on the order of minutes.
-2. A stop-gap solution that can be set up and activated within those minutes, which will power the station for the next ten to
- fifteen minutes, but which cannot power the station for the full round.
-3. A main power source which can be set up within those ten to fifteen minutes, and which can power the station for the
- rest of the round.
-
-
-
-
-
-Each phase of power generation scales in both complexity and power output. Stop-gap generation options are simple,
-immediate, and weak. Main power generation is complex, takes longer to set up, and supplies a large amount of power.
-
-Additionally, every one of the existing power generation options available today can be made to fit this pattern with
-only minor adjustments.
-
-## Round Start Power
-
-Round start power options are characterized by:
-
-1. Actively supplying power to the station at round start.
-2. Supplying only enough power to last until Stop-Gap power can be activated.
-
-Currently this means SMESs, and there is little reason to change this phase of power generation at this time.
-
-In the future this could be more exotic power options with extremely limited fuel and diffcult to obtain fuel, or any
-number of other possibilities.
-
-## Stop-Gap Power
-
-The core characteristics of stop-gap power generation options are that they are:
-
-1. Clear and easy to set up.
-2. Immediately available to set up on round start.
-3. Not enough to keep the station powered through the full round.
-
-As it stands the only power generation option which comes close to handling this phase are the portable generators.
-However, as it stands maps would need to be tweaked to make it clear that use of the generators for this purpose is
-intended, by for instance including an array of them ready to be anchored and fueled within engineering it self.
-
-This is also a role which could be handled by the Antimatter Engine. Spawning a mostly-depleted jar of AME fuel, and
-removing the option for cargo to buy additional AME fuel would allow the AME to fulfill this role as-is.
-
-Finally, while solar power is not a good fit for primary power generation in this phase - its perpetual nature removing
-and time pressure - it does stand as a useful option to extend the length of the stop-gap power phase - and can be
-utilizied if engineering needs more time to set up main power.
-
-## Main Power
-
-Main power generation options as proposed are characterized by the following:
-
-1. They are complex to set up.
-2. They take a good deal more time to set up than is available with Round Start power.
-3. They can power the station indefinitely, or at least longer than a typical round.
-
-With tweaks to the existing maps, the TEG, the Telsa, and the Singularity could all act as Main Power generation
-options. As it stands their setup has been drastically simplified, as they are currently serving as the next phase of
-power after round start power runs out - with no clear stop-gap options existing.
-
-With the additon of clear stop-gap options, the setup process for each of these could be made more complex. Each map
-could start with the components necessary for one or more of these main power options in storage - and require engineers
-to set them up almost from scratch.
-
-The additional time before blackout supplied by the stop-gap power options would allow this complex setup process to be
-completed without the station losing power.
-
-Furthermore, the addition of future main power generation options would no longer represent a direct burden on mappers.
-Without the need for immediate, rapid setup, ordering these options from cargo becomes a viable option. Maps would only
-need space to build these options - not have them mostly set up already.
-
-
-## Beyond Main Power
-
-The core pattern of power generation outlined at the beginning of this proposal is enough on its own to bring engineering
-and power genration to a more consistent and engaging place. This section will outline some ideas for moving beyond that
-core, but should be treated as less important than the rest of this proposal.
-
-As it stands engineering is incentivized to produce enough power for the station to sustain itself, and there is little
-incentive to go beyond that.
-
-Having methods to turn excess power into other resources or commodities would change this. Some of these options could
-even be locked to specific methods of main power generation - adding to the considerations when choosing a main power
-generation method. The following are a few examples of what could be possible:
-
-* Allow the AME to be deconstructed and rebuilt along with some of the radiation collectors to capture AME fuel - which
- could be sold by cargo for a significant amount.
-* Special rods could be installed beside the Tesla which would sink the power from those arcs, but which would allow
- revival of rotted corpses.
-* Science could research a machine which allows for the direct production of base resources - but which has insane power
- requirements.
-* An experimental convection oven which must be directly attached to the TEG, sapping some of its power but allowing the
- creation of powerful baked goods.
-
-While secondary to the core proposal, I do believe that looking for incentives to generate more than just enough power
-will be valuable to gameplay long term.
-
-
diff --git a/src/en/proposals/theshued-thief.md b/src/en/proposals/theshued-thief.md
deleted file mode 100644
index f4dc00338..000000000
--- a/src/en/proposals/theshued-thief.md
+++ /dev/null
@@ -1,98 +0,0 @@
-# Minor Antagonist: Thief
-the purpose of this proposal is to add a new minor antagonist to the game, the Thief.
-This antagonist's specialty is stealing various items, structures and animals from the station, without resorting to violence or killing.
-
-## Appearance
-Thieves is a small addition to the other game modes. At the moment, thieves can only appear in Traitors and Revolution modes with 50% chance. There can be from 1 to 3 thieves in total, and they are chosen among random players at the beginning of the round. The exceptions are Command and Security players.
-
-When appear, the Thief gains 1 new item, "undetermined toolbox", which allows you to choose your play style by giving you starter gear.
-
-## Customizable play style
-Inside the Thief's backpack, there are 3 things by default:
-1) Thief's Gloves, which allow you to steal things from people unnoticed
-2) Undetermined toolbox, allows you select up to 2 starter equipment kit
-
-Suggested equipment sets for toolbox:
-| Name | Content |
-|----------|:-------------|
-| Thief Pinpointer | Includes: A pinpointer that shows the direction to an object of interest to the owner thief. When switched on or off, it selects a random object for which the thief has not yet completed the target. |
-| Chameleon's Set | Includes: A set of chameleon clothes. |
-| Bearcatcher's kit | Includes 2 C4s, multitool, jaws of life, advanced welder meson glasses and insulated gloves.|
-| Chemistry kit | It includes a storage implanter, a dna scrambler implanter, and ephedrine bottle, omnizine bottle.|
-| Syndie Set | Includes: Agent ID, syndie-cigarettes, syndie pAI, 10 TC (usless for thief, needed for traitor. Communication?)|
-| Sleeper Set | Includes: a hipopen, a set of 3 nocturine vials, a nitrous oxide cylinder, a set of syndicate pajamas. |
-| Communicator's kit | Includes master key for all station channels, radio jammer, voice mask, portable crew monitor and lots of money for business deals. |
-| Smuggler's kit | Includes a fulton beacon, 10 fultons and invisible crate. |
-
-## Thief goals
-The thief's targets are chosen according to the following pattern:
-With a 50% chance, a difficult target is added to steal a structure or animal. The remaining targets are selected from a pool of small item theft or collection targets until the total difficulty is sufficient. The final goal is always to escape the station alive and unarrested.
-
-### Steal the item
-The goal is to steal a certain item from the station, and keep it with you by the end of the round.
-The target list consists of random objects whose abduction can lead to interesting scenarios. This list can include both easy and extremely difficult targets.
-This list should not include items that Traitors require: if they are successfully stolen by a thief, the goal becomes too difficult for the Traitor to accomplish.
-
-| Item |
-|------|
-| Forensic Scanner |
-| AmmoTechFabCircuitboard |
-| ClothingHeadHatWarden |
-| ClothingOuterHardsuitVoidParamed |
-| MedicalTechFabCircuitboard |
-| ClothingHeadsetAltMedical |
-| RnDServerMachineCircuitboard |
-| FireAxe |
-| RCD |
-| AmePart |
-| ExpeditionsCircuitboard |
-| CargoShuttleCircuitboard |
-| SalvageShuttleCircuitboard |
-| ClothingEyesHudBeer |
-| Bible |
-| ClothingNeckGoldmedal |
-| ClothingNeckClownmedal |
-
-
-## Steal the structure
-the goal is to steal a large object that doesn't fit in your inventory. For the goal to be fulfilled, the structure must be near the thief at the end of the round.
-
-| Structure |
-|-----------|
-| Nucler Bomb |
-| The captain fax |
-| Security Segway |
-| Chemical Dispencer |
-| Alien artifact |
-| Heater or Freezer |
-| Teg part |
-| Meat Spike |
-| Hydroponic tray |
-| Booze dispencer |
-| Altar |
-
-## Steal the animal
-The goal is to steal and have said animal next to you by the end of the round. The animal must be alive.
-
-| Animal |
-|--------|
-| any animal with a name (except Ian) |
-
-## Collecting
-the goal is to accumulate a large number of specific items and have them with you by the end of the round.
-
-| Item |
-|------|
-| Head's Cloaks |
-| Head's Bedsheets |
-| Stamps |
-| Door Remotes |
-| Research Disks |
-| Figurines |
-| ID Cards |
-| Cannabis |
-
-## Expected gameplay
-Given the restriction on violence, gameplay as a thief involves maximum stealth. The thief evaluates the quests he has received, and chooses 2 sets of items to choose from that can help him best. The thief tries to steal the specified targets stealthily, trying not to get caught. If caught, the thief may not fight. But even the specified list of targets does not allow the security service to execute him or put him permanently in a cell.
-
-This means that a thief, once released, can always try again.
diff --git a/src/en/proposals/tomleys-game-director.md b/src/en/proposals/tomleys-game-director.md
deleted file mode 100644
index 09508f7bf..000000000
--- a/src/en/proposals/tomleys-game-director.md
+++ /dev/null
@@ -1,212 +0,0 @@
-# Game Director
-
-| Designers | Implemented | GitHub Links |
-|---|---|---|
-| tom-leys (RecallSingularity) | :information_source: Open PR | https://github.com/space-wizards/space-station-14/pull/16548 |
-
-## Overview
-
-Triggers game events to attain a chaos goal. Goal varies during each round to create variety.
-By measuring and varying chaos, the director keeps the challenge each round within a fun band. It reacts to player success
-or failure by tailoring future events based on current chaos measured.
-
-The Game Director adds new game modes, initially CombatDynamic and CalmDynamic. They can only be triggered by an admin
-running for instance `addgamerule CalmDynamic`. A later PR could put them into automatic rotation.
-
-## Background
-
-Events in SS14 trigger challenges or benefits for players. They might spawn spiders, dragons or zombies. Traitors
-come on board, Nukies attack or vents spew grease. Pizza might be delivered or power is turned off to sections of the station.
-
-Historically events trigger in a few ways:
-
-- At round start (for instance a zombie or nukie round begins)
-- Randomly, every 5 minutes or so (extended rounds)
-- Randomly, at an increasing pace (survival rounds, now discontinued)
-- Due to admin commands such as `addgamerule`
-- Hand created by admins adding entities and using admin tools.
-
-In the absense of administrator intervention, extended rounds can become boring and monotonous. Zombie or Nukie rounds
-are often boring for a period, intense for a period and if the station is saved boring again.
-
-Due to the random nature of the extended round system, events cannot be too dangerous or too beneficial to the players
-or through RNG they are likely to trigger at the worst time. One station might be flooded with spiders, a dragon and space lube
-under every vent while another only suffers a few rats and some flickering lights.
-
-The Game Director aims to provide an alternative to the extended mode that is flexible and drives a fun set of events
-towards a larger set of Chaos Goals. A wide array of extreme events both positive and negative can then be added to the game
-safe in the knowledge they will be run at suitable times rather than randomly.
-
-Discord Topic: https://discord.com/channels/310555209753690112/1110002801448329226
-GitHub PR: https://github.com/space-wizards/space-station-14/pull/16548
-
-### Car Metaphor
-
-Imagine you are driving on the highway. You look at the metric of your speedometer to see how fast you are driving. The
-speed limit specifies how fast you should go. You then pick either the apply gas, reduce gas or turn on radio events to
-best match the car speed to the goal set by the speed limit. The director works in a similar way.
-
-## Basic method
-
-- **Chaos** - Metrics we are measuring and controlling with each event
-- **Story** - Determines a series of Chaos Goals
-- **Metrics** - Estimate the existing chaos on station
-- **Events** - Have a predicted effect on chaos
-- **Game Director** - Pick best Event to achieve story Metrics
-
-1. **Wait** until it is time for next event
-2. Run **metrics** to measure current **Chaos**
-3. Advance **StoryBeat** and **Story** (over time or based on Chaos)
-4. Read **desired Chaos** from **current StoryBeat**
-5. **Rank** valid events to achieve near desired chaos
-6. Run **best event**
-
-## Chaos - Metrics of a station
-
-We want to measure how bad the Chaos is right now. If the station is doing well, the lights are on and the floor is clean,
-we expect low chaos scores. If the lights are out, the place is spaced and enemies are roaming the station, we want high
-chaos scores.
-
-To best tailor events to the exact situation on the station, chaos is measured by several metrics.
-The solution to hunger is pizzas. The solution to enemies might be a squad of reinforcements. A station
-that is too peaceful is ready for meteorites, spiders or other hazards.
-
-A wide range of challenges should be reflected by moderate chaos values for every metric to best challenge all departments
-on the station. For instance many new anomolies will keep science busy and potentially annoy other players. But anomolies won't
-tax security the same way traitors or spiders would.
-
-Obvious metrics, where a perfect station has chaos of 0 and it increases as things get messy:
-- Hunger
-- Thirst
-- Anomaly
-- Death
-- Medical
-- Security
-- Power
-- Atmos
-- Mess
-
-Combat metrics:
-- Friend - negative to represent how many friendlies are alive on the station
-- Hostile - Score for all antags and monsters
-- Combat - Friend + Hostile. <0 if crew is strong. 0 if balanced (fighting). >0 indicates crew is losing.
-
-## Story - Determines a series of Chaos Goals
-
-Stories are composed of StoryBeats and determine the Chaos Goals over a 15-30 minute period within a round.
-
-Beats generally last 5 minutes each, though they might end early if chaos hits certain thresholds.
-These are called `endIfAnyWorse` and `endIfAllBetter`, useful if there is too much war, or perhaps too much peace.
-
-Once a story beat has ended, the director will move to the next beat in the story. Once a given story has finished, the
-director will pick one of its stories at random to start.
-
-Player experience in SS14 should have both its highs and lows. A peaceful extended shift can become boring with no challenges
-to overcome together. An overly intense battle might kill half the crew and leave the station in disorder that we cannot recover from.
-What we want is a middle ground with some variation.
-
-The ideal story has a mix of both, with order followed by disorder and then a chance to recover and rebuild. We want variety with
-pleasant cycles in intensity potentially building towards an overall climax as the round progresses.
-
-### Dynamic Game Modes:
-
-Each game mode preset specifies which stories will run and so determines the tone for the experience created by
-the director.
-
-The number of stories and story beats is quite small right now, as we add more content to the game we will also expand
-the range of stories followed by the director to increase the tonal variety between rounds.
-
-#### CombatDynamic
-Contains combat stories and so will create a station with some fighting
-- **RelaxedAttack** - Peace -> AttackMild -> EngineeringIssues
-- **ScienceAttack** - Peace -> MadScience -> AttackMild -> Peace -> EngineeringIssues -> RepairStation
-- **MajorCombat** - Peace -> AttackMild -> EngineeringIssues -> Attackers -> RestoreOrder -> RepairStation -> Peace
-
-#### CalmDynamic
-More like an extended round, has a balance of minor chaos events
-- **Relaxed** - Peace -> AttackMild -> EngineeringIssues
-- **Science** - Peace -> MadScience -> Peace -> EngineeringIssues -> RepairStation
-
-### Story Beats
-Some beats deliberately drive moderate or high chaos for a period of time. Others bring specific types of chaos to near
-0 to encourage the director to pick helpful events until the station is moderate again.
-
-The hostile story beats tend to end if the station chaos rises too high. The recovery ones end if the chaos drops low
-enough. By incorporating both into a story we can expect some hostile events, a period of chaos followed by positive
-events and a period of recovery.
-
-- **Peace** - Minor Chaos across a wide range
-- **PowerIssues** - Create high engineering chaos
-- **MadScience** - Create high Science chaos
-- **Attackers** - Drive high combat
-- **AttackMild** - Drive medium combat
-- **RestoreOrder** - Send help to quell disorder on the station
-- **RepairStation** - Repair that station
-
-## Metrics - Estimate the existing chaos on station
-
-A number of systems called "Metrics" are used to summarize the chaos levels. Metrics each stand alone and so it will be
-easy to add or remove them as the game matures.
-
-Metrics could subscribe to relevant events and dynamically adjust their scores as events occur on the station. Or they
-can do a single pass through the component system when run. The single pass approach has been preferred in favor of its
-stability and simplicity for now.
-
-#### Metrics at the moment
-- **AnomalyMetric** - Are there many? Are they out of control? Writes to "Anomaly"
-- **CombatMetric** - Who is on the station? How injured are our friends? Writes to "Hostiles", "Friendlies", "Death" and "Medical"
-- **DoorMetric** - Uses doors as a proxy to surveying the ship for danger. Writes to "Security", "Atmos" and "Power"
-- **FoodMetric** - How hungry are the friendly crew? Writes to "Hunger" and "Thirst"
-- **PuddleMetric** - How messy is the station (partially as a proxy for safety). Writes to "Mess"
-
-I expect that as we describe a situation we want the Director to react to we will introduce further metrics to give us
-richer insight into the station. We might want trust metrics based on how many traitors there are. Or staff / department
-metrics based on staffing issues and role deaths.
-
-## Events - Have a predicted effect on chaos
-
-How do we describe what an event does?
-
-Events have a metric called "Chaos" which describes different types of negative effects they bring to the station.
-Good events cause negative chaos.
-
-If our chaos estimates for each event are accurate, the game director can easily control chaos by picking the best events
-for the current story beat.
-
-### Negative events increase chaos
-SpiderSpawn:
- - Hostiles: 40 - New hostiles are introduced
- - Friends: 20 - Friends are likely to die
- - Medical: 150 - Medical will have wounds to heal
-
-### Positive events reduce chaos
-PizzaPartySmall:
- - Hunger: -80 - The pizza party satisfies hunger
- - Thirst: -40 - And also thirst
-
-## Game Director - Pick best Event to achieve story Metrics
-
-Each of the **story beats** from above has a matching chaos level, specifying factors that we care about at that point
-in the story along with target values for those **Chaos factors**.
-
-Once we know what **Chaos metrics** we currently attempting to achieve, we have a chance to select the correct event.
-
-- The **Story Beat** has told us what chaos we want.
-- The **Metrics** tell us what chaos the station currently has.
-- Each **StationEvent** has a Chaos field predicting that event's impact
-
-So we iterate through all the possible events, choose the one which moves the station chaos nearest to our goal and set
-that event into action. Simple!
-
-The whole process is richly logged into the admin log (under GameDirector) so the admins have insight into what the director
-is attempting to achieve.
-
-# Conclusion
-
-The Game Director system will allow us to author specific experiences that are gated on how chaotic the station has become.
-
-The more events we introduce to the game with clear chaos outcomes, the better the system will be at guiding the station
-through a specific narrative experience.
-
-The data driven nature of the metrics and story data means that a wide variety of narrative outcomes and station-specific
-events can all be achieved through the same system.
\ No newline at end of file
From 7da8f8e21f3bf1bd32af8808fcda175a39a61dc0 Mon Sep 17 00:00:00 2001
From: Kevin Zheng
Date: Tue, 27 Feb 2024 23:13:13 -0800
Subject: [PATCH 24/80] Update gitignore
---
.gitignore | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/.gitignore b/.gitignore
index d47934e47..fa0a061c6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,6 @@
book
.idea/
+
+# editor files
+.*~
+*.swp
From 23906884bcd21c38cb0938fb3958020a143cc746 Mon Sep 17 00:00:00 2001
From: Kevin Zheng
Date: Sat, 20 Apr 2024 22:06:47 -0700
Subject: [PATCH 25/80] Convert to table
---
src/en/general-development/work-groups.md | 64 +++++++++--------------
1 file changed, 25 insertions(+), 39 deletions(-)
diff --git a/src/en/general-development/work-groups.md b/src/en/general-development/work-groups.md
index e8a87aca5..c5917e522 100644
--- a/src/en/general-development/work-groups.md
+++ b/src/en/general-development/work-groups.md
@@ -5,48 +5,34 @@ Work-groups are effectively the design equivalent to Code-Owners. Each work grou
Each work group is responsible for maintaining corresponding design and pr guidelines documents in the docs repo that outlines the current and intended design for that game area, along with what is acceptible design/quality for a PR in that game area. Maintainers that are not part of any work groups are generalists, and while they might not be fully up to date with the design of a game-area they can still help answer questions.
-## Maintainer work groups:
-This list is updated less than discord/github, for a more accurate list look at the github work-group teams or discord roles.
+## Current Work Groups
### Game-Wide
-- [Accessibility:](../space-station-14/areas/core/accessibility.md)\
- Bhijn & Myr(deathride58), AJCM
-- [Admin Tooling:](../space-station-14/areas/core/admin-tools.md)\
- Jezithyr, Chief-Engineer, Vasilis, Julian, Bhijn & Myr(deathride58)
-- [Art:](../space-station-14/areas/core/art.md)\
- EmoGarbage, Flareguy
-- [Character/Species:](../space-station-14/areas/core/characters-species.md)\
- Jezithyr, Lank, Vasilis, KeronSHB, Bhijn & Myr(deathride58), AJCM
-- [Combat:](../space-station-14/areas/core/combat.md)\
- Jezithyr, EmoGarbage, AJCM, KeronSHB, Bhijn & Myr(deathride58)
-- [Player Interaction:](../space-station-14/areas/core/player-interaction.md)\
-
-- [Mapping:](../space-station-14/areas/core/mapping.md)\
- Emmise
-- [Roleplay/Lore:](../space-station-14/areas/core/roleplay-lore.md)\
- Lank, KeronSHB, Vasilis
-- [Round Flow:](../space-station-14/areas/core/round-flow.md)\
- Jezithyr, EmoGarbage, Tayrthan, KeronSHB, Bhijn & Myr(deathride58), AJCM
-- [User Interface:](../space-station-14/areas/core/user-interface.md)\
- Jezithyr, EmoGarbage, AJCM, Julian, Bhijn & Myr(deathride58)
+
+| Group | Members |
+|-------|---------|
+| [Accessibility](../space-station-14/areas/core/accessibility.md) | Bhijn & Myr(deathride58), AJCM |
+| [Admin Tooling](../space-station-14/areas/core/admin-tools.md) | Jezithyr, Chief-Engineer, Vasilis, Julian, Bhijn & Myr(deathride58) |
+| [Art](../space-station-14/areas/core/art.md) | EmoGarbage, Flareguy |
+| [Character/Species](../space-station-14/areas/core/characters-species.md) | Jezithyr, Lank, Vasilis, KeronSHB, Bhijn & Myr(deathride58), AJCM |
+| [Combat](../space-station-14/areas/core/combat.md) | Jezithyr, EmoGarbage, AJCM, KeronSHB, Bhijn & Myr(deathride58) |
+| [Player Interaction](../space-station-14/areas/core/player-interaction.md) | |
+| [Mapping](../space-station-14/areas/core/mapping.md) | Emmise |
+| [Roleplay/Lore](../space-station-14/areas/core/roleplay-lore.md) | Lank, KeronSHB, Vasilis |
+| [Round Flow](../space-station-14/areas/core/round-flow.md) | Jezithyr, EmoGarbage, Tayrthan, KeronSHB, Bhijn & Myr(deathride58), AJCM |
+| [User Interface](../space-station-14/areas/core/user-interface.md) | Jezithyr, EmoGarbage, AJCM, Julian, Bhijn & Myr(deathride58) |
### Departments
-- [Atmos:](../space-station-14/areas/departments/atmos.md)\
- Jezithyr, KeronSHB, NotAFet(PartMedia)
-- [Cargo/Salvage:](../space-station-14/areas/departments/cargo-salvage.md)\
-
-- [Command:](../space-station-14/areas/departments/command.md)\
- KeronSHB, EmoGarbage, Vasilis
-- [Engineering:](../space-station-14/areas/departments/engineering.md)\
- Jezithyr, Julian, AJCM, KeronSHB
-- [Medical:](../space-station-14/areas/departments/medical.md)\
- Jezithyr, Vasilis, AJCM,
-- [Science:](../space-station-14/areas/departments/science.md)\
- Jezithyr, EmoGarbage, AJCM, Tayrtahn
-- [Security:](../space-station-14/areas/departments/security.md)\
- Lank(LankLTE), KeronSHB
-- [Service:](../space-station-14/areas/departments/service.md)\
- AJCM, Tayrtahn, NotAFet(PartMedia)
+| Group | Members |
+|-------|---------|
+| [Atmos](../space-station-14/areas/departments/atmos.md) | Jezithyr, KeronSHB, notafet(Partmedia) |
+| [Cargo/Salvage](../space-station-14/areas/departments/cargo-salvage.md) | |
+| [Command](../space-station-14/areas/departments/command.md) | KeronSHB, EmoGarbage, Vasilis |
+| [Engineering](../space-station-14/areas/departments/engineering.md) | Jezithyr, Julian, AJCM, KeronSHB |
+| [Medical](../space-station-14/areas/departments/medical.md) | Jezithyr, Vasilis, AJCM |
+| [Science](../space-station-14/areas/departments/science.md) | Jezithyr, EmoGarbage, AJCM, Tayrtahn |
+| [Security](../space-station-14/areas/departments/security.md) | Lank(LankLTE), KeronSHB |
+| [Service](../space-station-14/areas/departments/service.md) | AJCM, Tayrtahn, notafet(Partmedia) |
## For maintainers:
@@ -54,4 +40,4 @@ Work-groups are non exclusive, you can be in as many or as few as you want, howe
If you are not in a pr's associated work-group you can still review the PR, however you should make sure to read the relevant design documentation and PR guidelines before doing a review. Ideally, you should leave associated PRs to be reviewed by their work-group members, but it's fine to merge something as long as it fits the design and meets the guidelines.
-If you plan on being involved with a workgroup for a long time, please add yourself to the above list. Likewise, if you are on the list and leave the workgroup with no intention of returning to it, you should remove yourself from the list.
\ No newline at end of file
+If you plan on being involved with a workgroup for a long time, please add yourself to the above list. Likewise, if you are on the list and leave the workgroup with no intention of returning to it, you should remove yourself from the list.
From 7bd5c1883caafbb7b97ac1532b6233bc1c3a82aa Mon Sep 17 00:00:00 2001
From: Nemanja <98561806+EmoGarbage404@users.noreply.github.com>
Date: Sun, 21 Apr 2024 11:11:17 -0400
Subject: [PATCH 26/80] Add xenoarch doc to sidebar
---
src/SUMMARY.md | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 35a9c9786..930ecfeff 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -187,7 +187,7 @@ Space Station 14
- [Engineering](en/space-station-14/areas/departments/engineering.md)
- [PR Guidelines](en/space-station-14/areas/departments/engineering/guidelines.md)
- [Machine Upgrading Rework](en/space-station-14/areas/departments/engineering/proposals/emogarbage-machine-upgrading-rework.md)
- - [Construction](en/space-station-14/areas/departments/engineering/construction.md)\
+ - [Construction](en/space-station-14/areas/departments/engineering/construction.md)
- [Node Networks](en/space-station-14/areas/departments/engineering/node-networks.md)
- [Device Network](en/space-station-14/areas/departments/engineering/device-network.md)
- [Pow3r](en/space-station-14/areas/departments/engineering/pow3r.md)
@@ -213,6 +213,7 @@ Space Station 14
- [Anomaly Cores](en/space-station-14/areas/departments/science/anomaly-cores.md)
- [Proposals]()
+ - [XenoArch Redux (3MOArch)](en/space-station-14/areas/departments/science/proposals/xenoarch-redux.md)
- [Security](en/space-station-14/areas/departments/security.md)
- [PR Guidelines](en/space-station-14/areas/departments/security/guidelines.md)
From f54fb94001244a25ceb4f7d8bab5fcd860011906 Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Tue, 23 Apr 2024 18:20:54 +0200
Subject: [PATCH 27/80] Fix critical spelling mistake
---
src/en/general-development/work-groups.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/en/general-development/work-groups.md b/src/en/general-development/work-groups.md
index c5917e522..a1f16d2da 100644
--- a/src/en/general-development/work-groups.md
+++ b/src/en/general-development/work-groups.md
@@ -17,7 +17,7 @@ Each work group is responsible for maintaining corresponding design and pr guide
| [Character/Species](../space-station-14/areas/core/characters-species.md) | Jezithyr, Lank, Vasilis, KeronSHB, Bhijn & Myr(deathride58), AJCM |
| [Combat](../space-station-14/areas/core/combat.md) | Jezithyr, EmoGarbage, AJCM, KeronSHB, Bhijn & Myr(deathride58) |
| [Player Interaction](../space-station-14/areas/core/player-interaction.md) | |
-| [Mapping](../space-station-14/areas/core/mapping.md) | Emmise |
+| [Mapping](../space-station-14/areas/core/mapping.md) | Emisse |
| [Roleplay/Lore](../space-station-14/areas/core/roleplay-lore.md) | Lank, KeronSHB, Vasilis |
| [Round Flow](../space-station-14/areas/core/round-flow.md) | Jezithyr, EmoGarbage, Tayrthan, KeronSHB, Bhijn & Myr(deathride58), AJCM |
| [User Interface](../space-station-14/areas/core/user-interface.md) | Jezithyr, EmoGarbage, AJCM, Julian, Bhijn & Myr(deathride58) |
From 82d8b3a81b90b3874dc7206c2c0ed5c49a61f917 Mon Sep 17 00:00:00 2001
From: nikthechampiongr <32041239+nikthechampiongr@users.noreply.github.com>
Date: Tue, 23 Apr 2024 16:34:13 +0000
Subject: [PATCH 28/80] Admin minutes4 (#205)
Add minutes for 2024-03-30 admin meeting.
Also re-arranges the order of admin meetings to the same order as
maintainer meetings.
---
src/SUMMARY.md | 1 +
.../admin-meeting-2024-03-30.md | 183 ++++++++++++++++++
2 files changed, 184 insertions(+)
create mode 100644 src/en/admin-meetings/admin-meeting-2024-03-30.md
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 930ecfeff..a9e8a1219 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -352,3 +352,4 @@ Admin Meetings
- [2024-02-03](en/admin-meetings/admin-meeting-2024-02-03.md)
- [2024-02-17](en/admin-meetings/admin-meeting-2024-02-17.md)
- [2024-03-16](en/admin-meetings/admin-meeting-2024-03-16.md)
+- [2024-03-30](en/admin-meetings/admin-meeting-2024-03-30.md)
diff --git a/src/en/admin-meetings/admin-meeting-2024-03-30.md b/src/en/admin-meetings/admin-meeting-2024-03-30.md
new file mode 100644
index 000000000..04914bb2a
--- /dev/null
+++ b/src/en/admin-meetings/admin-meeting-2024-03-30.md
@@ -0,0 +1,183 @@
+# Admin Meeting 2024-03-30
+
+## Agenda
+
+
+- Brief updates from last meeting
+- Reduction votes without reduction times
+- Trialmin improvements
+- When do players playing as antags cause rule issues?
+- Review minutes
+
+## Topic Details
+
+
+### Brief updates from last meeting
+
+The last meeting's minutes are available at [link]
+
+#### Summary
+> Headmin magic has caused async trial promotions to happen. I didn't have time to write out this summary early so I'm not sure what other things should be included here.
+> -Chief_Engineer
+
+#### Meeting Goals
+
+1. Communicate updates related to items from the last meeting to admins attending the meeting.
+
+### Reduction votes without reduction times
+
+#### Summary
+
+> Can we put what time you want if you vote for reduction, Currently if not one mentions a time it defaults to 1 week. But if someone votes for something like 2 months and there are another 6 admins that did not define something that is a huge difference in reduction. Adding a time would be useful here.
+> Another thing to keep in mind is the ban time. Reductions are a reduction from a indef ban to a set time, not altering the start date of said ban. If they have already been banned for 2 weeks and we reduce to 1 week it was the same as if we had just removed.
+> -Repo
+
+> I think if people don't care enough to write out what they want the reduction to, then there's no issue with however many do care enough from determining the reduction time on their own.
+>
+> For reductions, I don't think it makes sense to reduce from the start of the ban because it makes two of the vote options actually mean the same thing sometimes instead of actually being different options. I think every time I've been asked, I've told people to reduce from the time that the vote was put up.
+> -Chief_Engineer
+
+#### Meeting Goals
+
+1. Determine if admins should be required to specify a reduction time if voting to reduce a ban.
+2. Determine if the time since the ban was placed is something admins are suggested to add to appeal votes.
+
+### Trialmin improvements
+
+#### Summary
+
+
+> Is there anything we can do that will improve how the next batch goes?
+>
+> Ideally specific actions that we know can be accomplished. Everyone knows it'd be better if mentors were able to get reviews in on time but no one is intentionally not doing them on time so we'd need ideas for how to make it more likely if that's something we wanted to focus on.
+> -Chief_Engineer
+
+#### Meeting Goals
+
+
+1. Determine a list of specific actions that can be taken to improve how the next batch of trialmins goes, including things related to selection.
+2. Optionally, determine any issues which may be plausible to be addressed before or considered during the next trial batch.
+
+### When do players playing as antags cause rule issues?
+
+#### Summary
+
+
+> There was a thread for this at [link removed] and there is a doc at [link removed]. The goal of this topic is to just ensure that the contents of the document are complete and accurate so that it can be forwarded to maintainers.
+> -Chief_Engineer
+
+#### Meeting Goals
+
+
+1. Ensure that the contents of the document are complete and accurate so that it can be forwarded to maintainers.
+
+### Review minutes
+
+#### Summary
+
+> The meeting minutes provide a record of the meeting for those who could not attend, and they are used to action decisions made in the meeting. For these reasons, it is important that they accurately represent what actually happened in the meeting.
+> -Chief_Engineer
+
+#### Meeting Goals
+
+1. Ensure that nothing important is missing or misrepresented in the minutes.
+2. Attempt to ensure that all topics have met their meeting goals. This can be done by ensuring that each meeting goal is directly addressed by the conclusion of the topic's minutes.
+3. Attempt to ensure that all conclusions fit into one of the following categories:
+ 1. Indicate that a meeting goal was completed.
+ 2. Are something actionable, meaning that they not only call for an action, but that action is specific enough that it does not require answering questions like "what exactly needs to be done?" or "how can this be done?"
+ 3. Clearly indicate that the meeting goals for the topic were not met. Examples: the discussion was tabled, the admin team did not reach a conclusion, the admin team was not able to make the conclusion actionable.
+
+```admonish info
+
+## Attendees
+
+- Chief_Engineer - Headmin
+- Skarlet - Headmin, Mediator
+- liltenhead - Headmin
+- ShadowCommander - Project Manager
+- nikthechampiongr - Propermin, Minutes Editor
+- Ryan_strudtfelt - Propermin
+- AjexRose - Propermin
+- TurboTracker - Propermin
+- Sphiral - Propermin
+- Kezu - Propermin
+- Repo - Propermin
+- Geekyhobbo - Propermin
+- eric156 - Propermin
+- CptJeanLuc - Propermin
+- Lucky - Propermin
+- Crazybrain - Propermin
+- Pancake - Propermin
+- Jarmer - Propermin
+- lunarcomets - Propermin
+- Violet - Trialmin
+
+```
+
+## Minutes
+
+### Brief updates from last meeting
+
+- Headmin decision has led to asynchronous trialmin promotions being adopted.
+
+
+
+### Reduction votes without reduction times
+
+- Admins will be required to provide a reduction time with their reduction vote and be able to justify it.
+ - This could be expanded to require admins justify their votes in general, not just reduce.
+ - Since many times the reason may have already been stated by another admin, it will be possible to simply react/reply to a reason and time you agree with.
+- Reduction times will be applied from the time a vote was made.
+ - Reductions from the time the vote was placed may sometime "add" onto a ban should admins vote for how much time the ban is worth, but this should solveably by just making this standard clear.
+ - Reductions from the time the ban was made may cause confusion, and will often lead to the options for reduce/accept to mean the same thing if the proposed reduction time is shorter than the time the appeallant has been banned for.
+- On deciding which reduction to apply, an average or a mean can be used for different admin suggestions.
+- Alternatively, we could require consensus in the appeal thread and call upon headmins to break a stalemate or have a vote.
+- Appeals will display the recommended ban duration as set out by the admin policy.
+- SS14.Admin issues can be made to add QOL features to ban appeal votes, like copying relative time of the ban in discord format
+
+```admonish info "Conclusion"
+
+#### Conclusion
+
+Consensus was reached to require admins to justify their reduction votes and provide a reduction time, applying reductions from the time the vote was started, and presenting the recommended ban time on appeal votes. More discussion is needed to decide how to resolve disputes on what the reduction time should be.
+
+```
+
+
+
+
+### Trialmin improvements
+
+- A clear schedule must be made for Mentors to provide reviews.
+- It should be clearer for regular admins how they can pass along feedback, and how to interract with trialmins.
+- The propermin wide thread for trialmin reviews will be brought back to allow for feedback to be more easily given from propermins to mentors to trialmins.
+ - Admins derailing that thread will be 1984'd. We will also have a slowmode to ensure this.
+- Trialmins will be prohibited from taking part in events in general until the last part of the trial where they are proficient with the admin tools and aware of what's appropriate.
+ - This will likely just be the last 2 weeks of their trial as decided by the Mentors.
+- A gantt chart - jeanluc - CE
+- Relax requirements on when reviews will be put out. If there has not been sufficient activity to make a review then one will not be made.
+- Make it clear to new trialmins that a trial will on average last 2 months. This will be done on the application. They should not feel pressured to make excessives notes/bans, or spend long periods of time in game "to get good reviews".
+- Trialmins should know that they are able to reach out to any and all admins at any time for assistance.
+
+```admonish info "Conclusion"
+
+#### Conclusion
+
+Consensus was reached to bring back the propermin wide thread for trialmin reviews, the mentor specific channel and threads will remain. Additionally trialmins will now be prohibited from taking part in events until the last weeks of their trial where they will be able to do them under supervision. Reviews will be put out when mentors believe it is appropriate, otherwise that week will be skipped. Trialmins need to be made aware that a trial is a long term commitment and that they shouldn't be expending extreme amount of time in adminning and should take proper breaks. They should also not be scared to reach out to the entire admin team for any question they may have.
+
+```
+
+### When do players playing as antags cause rule issues?
+
+- The contents of the doc were discussed, and expanded upon.
+
+
+### Discussion outside Agenda Items
+
+
+- Murderboning is currently in a very large gray area and requires clarification. Will be brought up in a future meeting.
+
+## Overall Conclusion
+
+
+Reduce votes will now require justification and a provided time from admins with the reduction being applied from the time the vote started. Trialmins will now only be allowed to take part in events, and host them with supervision near the end of their trial. The propermin thread for trialmins will be brought back with a slowmode to prevent derailing. Trialmins still need to be made more aware of what's expected of them so they stop living inside the computer to admin. They should also know that they should reach out to the entire admin team for assistance. The review process will be improved to be less stringent on requiring a review every week, and to make guidelines clearer.
From a5a86e4731306b2ca59b4238e8c741b55d34d3be Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Wed, 24 Apr 2024 09:49:41 +0200
Subject: [PATCH 29/80] Transfer jr. maints to content maints, Add julian
---
src/en/community/space-wizards-maintainer-list.md | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/en/community/space-wizards-maintainer-list.md b/src/en/community/space-wizards-maintainer-list.md
index 9be18c796..e0d169be7 100644
--- a/src/en/community/space-wizards-maintainer-list.md
+++ b/src/en/community/space-wizards-maintainer-list.md
@@ -25,8 +25,7 @@ Content Maintainers:
- [Partmedia](https://github.com/Partmedia) - @notafet (774744999379599360)
- [Emisse](https://github.com/Emisse) - @emisse (109430489684705280)
- [Chief-Engineer](https://github.com/Chief-Engineer) - @am.ghost (267392122179682307)
-
-Junior Maintainers:
+- [juliangiebel](https://github.com/juliangiebel) - @julian_g (234313113766199297)
- [Tayrtahn](https://github.com/Tayrtahn) - @tayrtahn (147050540214386689)
- [deathride58](https://github.com/deathride58) - @bhijn (77867936647225344)
- [VasilisThePikachu](https://github.com/VasilisThePikachu) - @vasilisiscool (322708417540259841)
From c2173908a996cf8c3f7536c8f0400389870a5ef7 Mon Sep 17 00:00:00 2001
From: Jezithyr
Date: Wed, 24 Apr 2024 02:58:17 -0700
Subject: [PATCH 30/80] Flattened the documentation tree
Also fixed TOML redirects, created new core tech category
---
book.toml | 25 +--
src/SUMMARY.md | 192 ++++++++++--------
.../general-development/feature-proposals.md | 2 +-
.../expected-feature-proposal-decorum.md | 2 +-
src/en/general-development/work-groups.md | 36 ++--
.../{areas/core => }/accessibility.md | 0
.../core => }/accessibility/guidelines.md | 0
.../accessibility/proposals/.gitkeep | 0
.../{areas/core => }/admin-tools.md | 0
.../core => }/admin-tools/guidelines.md | 0
.../core => }/admin-tools/proposals/.gitkeep | 0
.../emogarbage-machine-upgrading-rework.md | 1 -
.../space-station-14/{areas/core => }/art.md | 0
.../{areas/core => }/art/displacement-maps.md | 0
.../{areas/core => }/art/guidelines.md | 0
.../{areas/core => }/art/proposals/.gitkeep | 0
.../core => }/character-species/guidelines.md | 0
.../character-species/proposals/.gitkeep | 0
.../{areas/core => }/characters-species.md | 0
.../{areas/core => }/combat.md | 0
.../{areas/core => }/combat/guidelines.md | 0
.../core => }/combat/proposals/.gitkeep | 0
.../{design.md => core-design.md} | 6 +-
.../core-design/departments.md | 1 +
.../{ => core-design}/design-principles.md | 0
.../medical => core-tech}/chemistry.md | 0
.../chemistry/metabolism.md | 0
.../chemistry/reactions.md | 0
.../chemistry/reagents.md | 0
.../chemistry/solution-containers.md | 2 +-
.../engineering => core-tech}/construction.md | 0
.../core/combat => core-tech}/destructible.md | 2 +-
.../device-network.md | 2 +-
.../space-station-14/core-tech/guidelines.md | 1 +
.../node-networks.md | 2 +-
.../core/round-flow => core-tech}/npcs.md | 0
.../{areas => }/departments.md | 0
.../{areas => }/departments/atmos.md | 0
.../atmos}/guidelines.md | 0
.../atmos/proposals/atmos-rework.md | 2 +-
.../{areas => }/departments/cargo-salvage.md | 0
.../cargo-salvage}/guidelines.md | 0
.../cargo-salvage}/proposals/.gitkeep | 0
.../{areas => }/departments/command.md | 0
.../command}/guidelines.md | 0
.../command}/proposals/.gitkeep | 0
.../{areas => }/departments/engineering.md | 0
.../engineering}/guidelines.md | 0
.../departments/engineering/pow3r.md | 0
.../proposals/engine-containment.md | 0
.../proposals/machine-upgrading-rework.md | 0
.../engineering/proposals/power-generation.md | 0
.../engineering/proposals/signaller-rework.md | 0
.../{areas => }/departments/medical.md | 0
.../medical}/guidelines.md | 0
.../medical}/proposals/.gitkeep | 0
.../{areas => }/departments/science.md | 0
.../departments/science/anomaly-cores.md | 0
.../science}/guidelines.md | 0
.../science/proposals/xenoarch-redux.md | 0
.../{areas => }/departments/security.md | 0
.../security}/guidelines.md | 0
.../security/proposals/genpop-prisoners.md | 0
.../{areas => }/departments/service.md | 0
.../service}/guidelines.md | 0
.../service/proposals/plant-genetics.md | 0
.../{areas/core => }/mapping.md | 0
.../{areas/core => }/mapping/dungeons.md | 2 +-
.../{areas/core => }/mapping/guidelines.md | 8 +-
.../core => }/mapping/guides/general-guide.md | 4 +-
.../command => mapping}/proposals/.gitkeep | 0
.../{areas/core => }/player-interaction.md | 0
.../player-interaction/cartridge-loaders.md | 0
.../player-interaction/grid-inventory.md | 6 +-
.../guidelines.md | 0
.../proposals/pda-messaging.md | 0
.../{areas/core => }/roleplay-lore.md | 0
.../science => roleplay-lore}/guidelines.md | 0
.../proposals/.gitkeep | 0
.../{areas/core => }/round-flow.md | 0
.../core => }/round-flow/antagonists.md | 0
.../round-flow/antagonists/exterminator.md | 0
.../core => }/round-flow/antagonists/thief.md | 0
.../security => round-flow}/guidelines.md | 0
.../proposals/cleanup-crew-gamemode.md | 0
.../round-flow/proposals/game-director.md | 0
.../proposals/pizza-delivery-critter.md | 0
.../round-flow/proposals/rogue-drones.md | 0
.../round-flow/proposals/turf-war.md | 0
.../{areas/core => }/user-interface.md | 0
.../service => user-interface}/guidelines.md | 0
.../user-interface/proposals/statpanels.md | 0
.../introduction-to-ss14-by-example.md | 2 +-
.../department-design-template.md | 39 ++++
src/index.md | 4 +-
95 files changed, 195 insertions(+), 146 deletions(-)
rename src/en/space-station-14/{areas/core => }/accessibility.md (100%)
rename src/en/space-station-14/{areas/core => }/accessibility/guidelines.md (100%)
rename src/en/space-station-14/{areas/core => }/accessibility/proposals/.gitkeep (100%)
rename src/en/space-station-14/{areas/core => }/admin-tools.md (100%)
rename src/en/space-station-14/{areas/core => }/admin-tools/guidelines.md (100%)
rename src/en/space-station-14/{areas/core => }/admin-tools/proposals/.gitkeep (100%)
delete mode 100644 src/en/space-station-14/areas/departments/engineering/proposals/emogarbage-machine-upgrading-rework.md
rename src/en/space-station-14/{areas/core => }/art.md (100%)
rename src/en/space-station-14/{areas/core => }/art/displacement-maps.md (100%)
rename src/en/space-station-14/{areas/core => }/art/guidelines.md (100%)
rename src/en/space-station-14/{areas/core => }/art/proposals/.gitkeep (100%)
rename src/en/space-station-14/{areas/core => }/character-species/guidelines.md (100%)
rename src/en/space-station-14/{areas/core => }/character-species/proposals/.gitkeep (100%)
rename src/en/space-station-14/{areas/core => }/characters-species.md (100%)
rename src/en/space-station-14/{areas/core => }/combat.md (100%)
rename src/en/space-station-14/{areas/core => }/combat/guidelines.md (100%)
rename src/en/space-station-14/{areas/core => }/combat/proposals/.gitkeep (100%)
rename src/en/space-station-14/{design.md => core-design.md} (94%)
create mode 100644 src/en/space-station-14/core-design/departments.md
rename src/en/space-station-14/{ => core-design}/design-principles.md (100%)
rename src/en/space-station-14/{areas/departments/medical => core-tech}/chemistry.md (100%)
rename src/en/space-station-14/{areas/departments/medical => core-tech}/chemistry/metabolism.md (100%)
rename src/en/space-station-14/{areas/departments/medical => core-tech}/chemistry/reactions.md (100%)
rename src/en/space-station-14/{areas/departments/medical => core-tech}/chemistry/reagents.md (100%)
rename src/en/space-station-14/{areas/departments/medical => core-tech}/chemistry/solution-containers.md (99%)
rename src/en/space-station-14/{areas/departments/engineering => core-tech}/construction.md (100%)
rename src/en/space-station-14/{areas/core/combat => core-tech}/destructible.md (99%)
rename src/en/space-station-14/{areas/departments/engineering => core-tech}/device-network.md (99%)
create mode 100644 src/en/space-station-14/core-tech/guidelines.md
rename src/en/space-station-14/{areas/departments/engineering => core-tech}/node-networks.md (99%)
rename src/en/space-station-14/{areas/core/round-flow => core-tech}/npcs.md (100%)
rename src/en/space-station-14/{areas => }/departments.md (100%)
rename src/en/space-station-14/{areas => }/departments/atmos.md (100%)
rename src/en/space-station-14/{areas/core/player-interaction => departments/atmos}/guidelines.md (100%)
rename src/en/space-station-14/{areas => }/departments/atmos/proposals/atmos-rework.md (97%)
rename src/en/space-station-14/{areas => }/departments/cargo-salvage.md (100%)
rename src/en/space-station-14/{areas/core/roleplay-lore => departments/cargo-salvage}/guidelines.md (100%)
rename src/en/space-station-14/{areas/core/mapping => departments/cargo-salvage}/proposals/.gitkeep (100%)
rename src/en/space-station-14/{areas => }/departments/command.md (100%)
rename src/en/space-station-14/{areas/core/round-flow => departments/command}/guidelines.md (100%)
rename src/en/space-station-14/{areas/core/roleplay-lore => departments/command}/proposals/.gitkeep (100%)
rename src/en/space-station-14/{areas => }/departments/engineering.md (100%)
rename src/en/space-station-14/{areas/core/user-interface => departments/engineering}/guidelines.md (100%)
rename src/en/space-station-14/{areas => }/departments/engineering/pow3r.md (100%)
rename src/en/space-station-14/{areas => }/departments/engineering/proposals/engine-containment.md (100%)
rename src/en/space-station-14/{areas => }/departments/engineering/proposals/machine-upgrading-rework.md (100%)
rename src/en/space-station-14/{areas => }/departments/engineering/proposals/power-generation.md (100%)
rename src/en/space-station-14/{areas => }/departments/engineering/proposals/signaller-rework.md (100%)
rename src/en/space-station-14/{areas => }/departments/medical.md (100%)
rename src/en/space-station-14/{areas/departments/atmos => departments/medical}/guidelines.md (100%)
rename src/en/space-station-14/{areas/departments/cargo-salvage => departments/medical}/proposals/.gitkeep (100%)
rename src/en/space-station-14/{areas => }/departments/science.md (100%)
rename src/en/space-station-14/{areas => }/departments/science/anomaly-cores.md (100%)
rename src/en/space-station-14/{areas/departments/cargo-salvage => departments/science}/guidelines.md (100%)
rename src/en/space-station-14/{areas => }/departments/science/proposals/xenoarch-redux.md (100%)
rename src/en/space-station-14/{areas => }/departments/security.md (100%)
rename src/en/space-station-14/{areas/departments/command => departments/security}/guidelines.md (100%)
rename src/en/space-station-14/{areas => }/departments/security/proposals/genpop-prisoners.md (100%)
rename src/en/space-station-14/{areas => }/departments/service.md (100%)
rename src/en/space-station-14/{areas/departments/engineering => departments/service}/guidelines.md (100%)
rename src/en/space-station-14/{areas => }/departments/service/proposals/plant-genetics.md (100%)
rename src/en/space-station-14/{areas/core => }/mapping.md (100%)
rename src/en/space-station-14/{areas/core => }/mapping/dungeons.md (97%)
rename src/en/space-station-14/{areas/core => }/mapping/guidelines.md (97%)
rename src/en/space-station-14/{areas/core => }/mapping/guides/general-guide.md (98%)
rename src/en/space-station-14/{areas/departments/command => mapping}/proposals/.gitkeep (100%)
rename src/en/space-station-14/{areas/core => }/player-interaction.md (100%)
rename src/en/space-station-14/{areas/core => }/player-interaction/cartridge-loaders.md (100%)
rename src/en/space-station-14/{areas/core => }/player-interaction/grid-inventory.md (96%)
rename src/en/space-station-14/{areas/departments/medical => player-interaction}/guidelines.md (100%)
rename src/en/space-station-14/{areas/core => }/player-interaction/proposals/pda-messaging.md (100%)
rename src/en/space-station-14/{areas/core => }/roleplay-lore.md (100%)
rename src/en/space-station-14/{areas/departments/science => roleplay-lore}/guidelines.md (100%)
rename src/en/space-station-14/{areas/departments/medical => roleplay-lore}/proposals/.gitkeep (100%)
rename src/en/space-station-14/{areas/core => }/round-flow.md (100%)
rename src/en/space-station-14/{areas/core => }/round-flow/antagonists.md (100%)
rename src/en/space-station-14/{areas/core => }/round-flow/antagonists/exterminator.md (100%)
rename src/en/space-station-14/{areas/core => }/round-flow/antagonists/thief.md (100%)
rename src/en/space-station-14/{areas/departments/security => round-flow}/guidelines.md (100%)
rename src/en/space-station-14/{areas/core => }/round-flow/proposals/cleanup-crew-gamemode.md (100%)
rename src/en/space-station-14/{areas/core => }/round-flow/proposals/game-director.md (100%)
rename src/en/space-station-14/{areas/core => }/round-flow/proposals/pizza-delivery-critter.md (100%)
rename src/en/space-station-14/{areas/core => }/round-flow/proposals/rogue-drones.md (100%)
rename src/en/space-station-14/{areas/core => }/round-flow/proposals/turf-war.md (100%)
rename src/en/space-station-14/{areas/core => }/user-interface.md (100%)
rename src/en/space-station-14/{areas/departments/service => user-interface}/guidelines.md (100%)
rename src/en/space-station-14/{areas/core => }/user-interface/proposals/statpanels.md (100%)
create mode 100644 src/en/templates-docs/department-design-template.md
diff --git a/book.toml b/book.toml
index d8214035a..24d3c9561 100644
--- a/book.toml
+++ b/book.toml
@@ -56,13 +56,21 @@ warning-policy = "ignore" # false-positives like hell with absolute links & late
"/en/content/yaml/index.html" = "/en/general-development/tips/yaml-crash-course.html"
"/en/getting-started/pr-guideline/index.html" = "/en/general-development/codebase-info/pull-request-guidelines.html"
"/en/getting-started/conventions/index.html" = "/en/general-development/codebase-info/conventions.html"
-"/en/content/chemistry/index.html" = "/en/space-station-14/chemistry.html"
"/en/content/writing-guidebook-entries/index.html" = "/en/general-development/tips/writing-guidebook-entries.html"
-"/en/content/device-network/index.html" = "/en/space-station-14/device-network.html"
-"/en/content/pow3r/index.html" = "/en/spcae-station-14/pow3r.html"
+"/en/content/device-network/index.html" = "/en/space-station-14/core-tech/device-network.html"
+"/en/content/pow3r/index.html" = "/en/spcae-station-14/departments/engineering/pow3r.html"
# yes this one is correct
-"/en/content/construction/index/index.html" = "/en/space-station-14/construction.html"
-"/en/content/destructible/index.html" = "/en/space-station-14/destructible.html"
+"/en/content/construction/index/index.html" = "/en/space-station-14/core-tech/construction.html"
+"/en/content/destructible/index.html" = "/en/space-station-14/core-tech/destructible.html"
+"/en/content/mapping/index.html" = "/en/space-station-14/mapping/guides/general-guide.html"
+"/en/content/mapping-sins/index.html" = "/en/space-station-14/mapping/guidelines.html"
+"/en/content/mapping-checklist/index.html" = "/en/space-station-14/mapping/guidelines.html"
+"/en/content/dungeons/index.html" = "/en/space-station-14/mapping/dungeons.html"
+"/en/content/node-networks/index.html" = "/en/space-station-14/core-tech/node-networks.html"
+"/en/content/NPCs/index.html" = "/en/space-station-14/core-tech/npcs.html"
+"/en/content/cartridge-loader/index.html" = "/en/space-station-14/player-interaction/cartridge-loaders.html"
+"/en/content/chemistry/index.html" = "/en/space-station-14/core-tech/chemistry.html"
+
"/en/administration/commands/index.html" = "/en/community/admin/admin-tooling/admin-command-cookbook.html"
"/en/administration/tooling/index.html" = "/en/community/admin/admin-tooling.html"
"/en/administration/policy/index.html" = "/en/community/admin/wizards-den-admin-policy.html"
@@ -80,13 +88,6 @@ warning-policy = "ignore" # false-positives like hell with absolute links & late
"/en/getting-started/troubleshooting/index.html" = "/en/general-development/tips/troubleshooting-faq.html"
"/en/config-reference/index.html" = "/en/general-development/tips/config-file-reference.html"
"/en/technical-docs/codebase-organization/index.html" = "/en/general-development/codebase-info/codebase-organization.html"
-"/en/content/mapping/index.html" = "/en/space-station-14/mapping.html"
-"/en/content/mapping-sins/index.html" = "/en/space-station-14/mapping/mapping-sins.html"
-"/en/content/mapping-checklist/index.html" = "/en/space-station-14/mapping/mapping-checklist.html"
-"/en/content/dungeons/index.html" = "/en/space-station-14/dungeons.html"
-"/en/content/node-networks/index.html" = "/en/space-station-14/node-networks.html"
-"/en/content/NPCs/index.html" = "/en/space-station-14/npcs.html"
-"/en/content/cartridge-loader/index.html" = "/en/space-station-14/cartridge-loaders.html"
"/en/engine/ecs/index.html" = "/en/robust-toolbox/ecs.html"
"/en/engine/coordinate-systems/index.html" = "/en/robust-toolbox/coordinate-systems.html"
"/en/engine/net-entities/index.html" = "/en/robust-toolbox/netcode/net-entities.html"
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index a9e8a1219..cc3af6f06 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -100,131 +100,143 @@ Space Station 14
----------------------
-- [Design](en/space-station-14/design.md)
- - [Design Principles](en/space-station-14/design-principles.md)
-- [Game Areas]()
- - [Global]()
- - [Accessibility](en/space-station-14/areas/core/accessibility.md)
- - [PR Guidelines](en/space-station-14/areas/core/accessibility/guidelines.md)
-
- - [Proposals]()
+- [Core Design](en/space-station-14/core-design.md)
+ - [Design Principles](en/space-station-14/core-design/design-principles.md)
- - [Admin Tooling](en/space-station-14/areas/core/admin-tools.md)
- - [PR Guidelines](en/space-station-14/areas/core/admin-tools/guidelines.md)
-
- - [Proposals]()
+- [Core Tech]()
+ - [PR Guidelines](en/space-station-14/core-tech/guidelines.md)
+
+ - [Destructible](en/space-station-14/core-tech/destructible.md)
+ - [Construction](en/space-station-14/core-tech/construction.md)
+ - [Node Networks](en/space-station-14/core-tech/node-networks.md)
+ - [Displacement Maps](en/space-station-14/art/displacement-maps.md)
+ - [Device Network](en/space-station-14/core-tech/device-network.md)
+ - [NPCs](en/space-station-14/core-tech/npcs.md)
+ - [Chemistry](en/space-station-14/core-tech/chemistry.md)
+ - [Metabolism](en/space-station-14/core-tech/chemistry/metabolism.md)
+ - [Reactions](en/space-station-14/core-tech/chemistry/reactions.md)
+ - [Reagents](en/space-station-14/core-tech/chemistry/reagents.md)
+ - [Solution Containers](en/space-station-14/core-tech/chemistry/solution-containers.md)
+
+ - [Proposals]()
+
+- [Accessibility](en/space-station-14/accessibility.md)
+ - [PR Guidelines](en/space-station-14/accessibility/guidelines.md)
+
+ - [Proposals]()
- - [Art](en/space-station-14/areas/core/art.md)
- - [PR Guidelines](en/space-station-14/areas/core/art/guidelines.md)
- - [Displacement Maps](en/space-station-14/areas/core/art/displacement-maps.md)
+- [Admin Tooling](en/space-station-14/admin-tools.md)
+ - [PR Guidelines](en/space-station-14/admin-tools/guidelines.md)
+
+ - [Proposals]()
- - [Proposals]()
+- [Art](en/space-station-14/art.md)
+ - [PR Guidelines](en/space-station-14/art/guidelines.md)
+
+ - [Proposals]()
- - [Character/Species](en/space-station-14/areas/core/characters-species.md)
- - [PR Guidelines](en/space-station-14/areas/core/character-species/guidelines.md)
+- [Character/Species](en/space-station-14/characters-species.md)
+ - [PR Guidelines](en/space-station-14/character-species/guidelines.md)
- - [Proposals]()
+ - [Proposals]()
- - [Combat](en/space-station-14/areas/core/combat.md)
- - [PR Guidelines](en/space-station-14/areas/core/combat/guidelines.md)
- - [Destructible](en/space-station-14/areas/core/combat/destructible.md)
+- [Combat](en/space-station-14/combat.md)
+ - [PR Guidelines](en/space-station-14/combat/guidelines.md)
- - [Proposals]()
+ - [Proposals]()
- - [Mapping](en/space-station-14/areas/core/mapping.md)
- - [PR Guidelines](en/space-station-14/areas/core/mapping/guidelines.md)
- - [Dungeons](en/space-station-14/areas/core/mapping/dungeons.md)
- - [Guides]()
- - [General Guide](en/space-station-14/areas/core/mapping/guides/general-guide.md)
+- [Mapping](en/space-station-14/mapping.md)
+ - [PR Guidelines](en/space-station-14/mapping/guidelines.md)
+
+ - [Dungeons](en/space-station-14/mapping/dungeons.md)
+
+ - [Guides]()
+ - [General Guide](en/space-station-14/mapping/guides/general-guide.md)
- - [Proposals]()
+ - [Proposals]()
- - [Player Interaction](en/space-station-14/areas/core/player-interaction.md)
- - [PR Guidelines](en/space-station-14/areas/core/player-interaction/guidelines.md)
- - [PDA Messaging](en/space-station-14/areas/core/player-interaction/proposals/pda-messaging.md)
- - [Grid Inventory](en/space-station-14/areas/core/player-interaction/grid-inventory.md)
+- [Player Interaction](en/space-station-14/player-interaction.md)
+ - [PR Guidelines](en/space-station-14/player-interaction/guidelines.md)
+
+ - [PDA Messaging](en/space-station-14/player-interaction/proposals/pda-messaging.md)
+ - [Grid Inventory](en/space-station-14/player-interaction/grid-inventory.md)
- - [Proposals]()
+ - [Proposals]()
- - [Roleplay/Lore](en/space-station-14/areas/core/roleplay-lore.md)
- - [PR Guidelines](en/space-station-14/areas/core/roleplay-lore/guidelines.md)
+- [Roleplay/Lore](en/space-station-14/roleplay-lore.md)
+ - [PR Guidelines](en/space-station-14/roleplay-lore/guidelines.md)
- - [Proposals]()
-
- - [Roundflow](en/space-station-14/areas/core/round-flow.md)
- - [PR Guidelines](en/space-station-14/areas/core/round-flow/guidelines.md)
- - [Antagonists](en/space-station-14/areas/core/round-flow/antagonists.md)
- - [Exterimator](en/space-station-14/areas/core/round-flow/antagonists/exterminator.md)
- - [Thief](en/space-station-14/areas/core/round-flow/antagonists/thief.md)
+ - [Proposals]()
- - [Proposals]()
- - [Cleanup Crew Gamemode](en/space-station-14/areas/core/round-flow/proposals/cleanup-crew-gamemode.md)
- - [Game Director](en/space-station-14/areas/core/round-flow/proposals/game-director.md)
- - [Pizza Delivery Critter](en/space-station-14/areas/core/round-flow/proposals/pizza-delivery-critter.md)
- - [Rogue Drones](en/space-station-14/areas/core/round-flow/proposals/rogue-drones.md)
- - [Turf War](en/space-station-14/areas/core/round-flow/proposals/turf-war.md)
+- [Roundflow](en/space-station-14/round-flow.md)
+ - [PR Guidelines](en/space-station-14/round-flow/guidelines.md)
+
+ - [Antagonists](en/space-station-14/round-flow/antagonists.md)
+ - [Exterimator](en/space-station-14/round-flow/antagonists/exterminator.md)
+ - [Thief](en/space-station-14/round-flow/antagonists/thief.md)
+
+ - [Proposals]()
+ - [Cleanup Crew Gamemode](en/space-station-14/round-flow/proposals/cleanup-crew-gamemode.md)
+ - [Game Director](en/space-station-14/round-flow/proposals/game-director.md)
+ - [Pizza Delivery Critter](en/space-station-14/round-flow/proposals/pizza-delivery-critter.md)
+ - [Rogue Drones](en/space-station-14/round-flow/proposals/rogue-drones.md)
+ - [Turf War](en/space-station-14/round-flow/proposals/turf-war.md)
- - [User Interface](en/space-station-14/areas/core/user-interface.md)
- - [PR Guidelines](en/space-station-14/areas/core/user-interface/guidelines.md)
+- [User Interface](en/space-station-14/user-interface.md)
+ - [PR Guidelines](en/space-station-14/user-interface/guidelines.md)
- - [Proposals]()
- - [Stat Panels](en/space-station-14/areas/core/user-interface/proposals/statpanels.md)
+ - [Proposals]()
+ - [Stat Panels](en/space-station-14/user-interface/proposals/statpanels.md)
+- [Departments](en/space-station-14/core-design/departments.md)
+ - [Atmos](en/space-station-14/departments/atmos.md)
+ - [PR Guidelines](en/space-station-14/departments/atmos/guidelines.md)
- - [Departments](en/space-station-14/areas/departments.md)
- - [Atmos](en/space-station-14/areas/departments/atmos.md)
- - [PR Guidelines](en/space-station-14/areas/departments/atmos/guidelines.md)
- [Proposals]()
- - [Atmos Rework](en/space-station-14/areas/departments/atmos/proposals/atmos-rework.md)
+ - [Atmos Rework](en/space-station-14/departments/atmos/proposals/atmos-rework.md)
- - [Cargo/Salvage](en/space-station-14/areas/departments/cargo-salvage.md)
- - [PR Guidelines](en/space-station-14/areas/departments/cargo-salvage/guidelines.md)
+ - [Cargo/Salvage](en/space-station-14/departments/cargo-salvage.md)
+ - [PR Guidelines](en/space-station-14/departments/cargo-salvage/guidelines.md)
+
- [Proposals]()
- - [Command](en/space-station-14/areas/departments/command.md)
- - [PR Guidelines](en/space-station-14/areas/departments/command/guidelines.md)
+ - [Command](en/space-station-14/departments/command.md)
+ - [PR Guidelines](en/space-station-14/departments/command/guidelines.md)
- [Proposals]()
- - [Engineering](en/space-station-14/areas/departments/engineering.md)
- - [PR Guidelines](en/space-station-14/areas/departments/engineering/guidelines.md)
- - [Machine Upgrading Rework](en/space-station-14/areas/departments/engineering/proposals/emogarbage-machine-upgrading-rework.md)
- - [Construction](en/space-station-14/areas/departments/engineering/construction.md)
- - [Node Networks](en/space-station-14/areas/departments/engineering/node-networks.md)
- - [Device Network](en/space-station-14/areas/departments/engineering/device-network.md)
- - [Pow3r](en/space-station-14/areas/departments/engineering/pow3r.md)
+ - [Engineering](en/space-station-14/departments/engineering.md)
+ - [PR Guidelines](en/space-station-14/departments/engineering/guidelines.md)
+
+ - [Machine Upgrading Rework](en/space-station-14/departments/engineering/proposals/machine-upgrading-rework.md)
+ - [Pow3r](en/space-station-14/departments/engineering/pow3r.md)
- [Proposals]()
- - [Engine Containment](en/space-station-14/areas/departments/engineering/proposals/engine-containment.md)
- - [Machine Upgrading Rework](en/space-station-14/areas/departments/engineering/proposals/machine-upgrading-rework.md)
- - [Power Generation Rework](en/space-station-14/areas/departments/engineering/proposals/power-generation.md)
- - [Signaller Rework](en/space-station-14/areas/departments/engineering/proposals/signaller-rework.md)
-
- - [Medical](en/space-station-14/areas/departments/medical.md)
- - [PR Guidelines](en/space-station-14/areas/departments/medical/guidelines.md)
- - [Chemistry](en/space-station-14/areas/departments/medical/chemistry.md)
- - [Metabolism](en/space-station-14/areas/departments/medical/chemistry/metabolism.md)
- - [Reactions](en/space-station-14/areas/departments/medical/chemistry/reactions.md)
- - [Reagents](en/space-station-14/areas/departments/medical/chemistry/reagents.md)
- - [Solution Containers](en/space-station-14/areas/departments/medical/chemistry/solution-containers.md)
+ - [Engine Containment](en/space-station-14/departments/engineering/proposals/engine-containment.md)
+ - [Machine Upgrading Rework](en/space-station-14/departments/engineering/proposals/machine-upgrading-rework.md)
+ - [Power Generation Rework](en/space-station-14/departments/engineering/proposals/power-generation.md)
+ - [Signaller Rework](en/space-station-14/departments/engineering/proposals/signaller-rework.md)
+
+ - [Medical](en/space-station-14/departments/medical.md)
+ - [PR Guidelines](en/space-station-14/departments/medical/guidelines.md)
- [Proposals]()
- - [Science](en/space-station-14/areas/departments/science.md)
- - [PR Guidelines](en/space-station-14/areas/departments/science/guidelines.md)
- - [Anomaly Cores](en/space-station-14/areas/departments/science/anomaly-cores.md)
+ - [Science](en/space-station-14/departments/science.md)
+ - [PR Guidelines](en/space-station-14/departments/science/guidelines.md)
+ - [Anomaly Cores](en/space-station-14/departments/science/anomaly-cores.md)
- [Proposals]()
- - [XenoArch Redux (3MOArch)](en/space-station-14/areas/departments/science/proposals/xenoarch-redux.md)
+ - [XenoArch Redux (3MOArch)](en/space-station-14/departments/science/proposals/xenoarch-redux.md)
- - [Security](en/space-station-14/areas/departments/security.md)
- - [PR Guidelines](en/space-station-14/areas/departments/security/guidelines.md)
+ - [Security](en/space-station-14/departments/security.md)
+ - [PR Guidelines](en/space-station-14/departments/security/guidelines.md)
- [Proposals]()
- - [GenPop Prisoners](en/space-station-14/areas/departments/security/proposals/genpop-prisoners.md)
- - [Service](en/space-station-14/areas/departments/service.md)
- - [PR Guidelines](en/space-station-14/areas/departments/service/guidelines.md)
+ - [GenPop Prisoners](en/space-station-14/departments/security/proposals/genpop-prisoners.md)
+ - [Service](en/space-station-14/departments/service.md)
+ - [PR Guidelines](en/space-station-14/departments/service/guidelines.md)
- [Proposals]()
- - [Plant Genetics](en/space-station-14/areas/departments/service/proposals/plant-genetics.md)
+ - [Plant Genetics](en/space-station-14/departments/service/proposals/plant-genetics.md)
General Proposals
================
diff --git a/src/en/general-development/feature-proposals.md b/src/en/general-development/feature-proposals.md
index 3943e2210..8cb7346d1 100644
--- a/src/en/general-development/feature-proposals.md
+++ b/src/en/general-development/feature-proposals.md
@@ -6,7 +6,7 @@ If you are considering adding or reworking some major component of the game it's
1. Make a copy of the design proposal template located at `src/en/templates/proposal.md`.
-3. Read through [SS14's Core Design Documentation](../space-station-14/design.md) (for gameplay-related proposals).
+3. Read through [SS14's Core Design Documentation](../space-station-14/core-design.md) (for gameplay-related proposals).
4. Write your proposal (see [guide to editing docs](../meta/guide-to-editing-docs.md)).
diff --git a/src/en/general-development/feature-proposals/expected-feature-proposal-decorum.md b/src/en/general-development/feature-proposals/expected-feature-proposal-decorum.md
index 6f903f66b..53fd59b99 100644
--- a/src/en/general-development/feature-proposals/expected-feature-proposal-decorum.md
+++ b/src/en/general-development/feature-proposals/expected-feature-proposal-decorum.md
@@ -8,7 +8,7 @@
Any documents proposed:
-- Should conform to the basic [Core Game Design](../../space-station-14/design.md) as well as this document obviously.
+- Should conform to the basic [Core Game Design](../../space-station-14/core-design.md) as well as this document obviously.
- Should contain sufficient justification for their existence,
- Can be closed or drafted at maintainer discretion,
- Are a reflection of SS14 to others that may be interested in how the game is designed. Take note of that.
diff --git a/src/en/general-development/work-groups.md b/src/en/general-development/work-groups.md
index a1f16d2da..f2a846d9d 100644
--- a/src/en/general-development/work-groups.md
+++ b/src/en/general-development/work-groups.md
@@ -11,28 +11,28 @@ Each work group is responsible for maintaining corresponding design and pr guide
| Group | Members |
|-------|---------|
-| [Accessibility](../space-station-14/areas/core/accessibility.md) | Bhijn & Myr(deathride58), AJCM |
-| [Admin Tooling](../space-station-14/areas/core/admin-tools.md) | Jezithyr, Chief-Engineer, Vasilis, Julian, Bhijn & Myr(deathride58) |
-| [Art](../space-station-14/areas/core/art.md) | EmoGarbage, Flareguy |
-| [Character/Species](../space-station-14/areas/core/characters-species.md) | Jezithyr, Lank, Vasilis, KeronSHB, Bhijn & Myr(deathride58), AJCM |
-| [Combat](../space-station-14/areas/core/combat.md) | Jezithyr, EmoGarbage, AJCM, KeronSHB, Bhijn & Myr(deathride58) |
-| [Player Interaction](../space-station-14/areas/core/player-interaction.md) | |
-| [Mapping](../space-station-14/areas/core/mapping.md) | Emisse |
-| [Roleplay/Lore](../space-station-14/areas/core/roleplay-lore.md) | Lank, KeronSHB, Vasilis |
-| [Round Flow](../space-station-14/areas/core/round-flow.md) | Jezithyr, EmoGarbage, Tayrthan, KeronSHB, Bhijn & Myr(deathride58), AJCM |
-| [User Interface](../space-station-14/areas/core/user-interface.md) | Jezithyr, EmoGarbage, AJCM, Julian, Bhijn & Myr(deathride58) |
+| [Accessibility](../space-station-14/accessibility.md) | Bhijn & Myr(deathride58), AJCM |
+| [Admin Tooling](../space-station-14/admin-tools.md) | Jezithyr, Chief-Engineer, Vasilis, Julian, Bhijn & Myr(deathride58) |
+| [Art](../space-station-14/art.md) | EmoGarbage, Flareguy |
+| [Character/Species](../space-station-14/characters-species.md) | Jezithyr, Lank, Vasilis, KeronSHB, Bhijn & Myr(deathride58), AJCM |
+| [Combat](../space-station-14/combat.md) | Jezithyr, EmoGarbage, AJCM, KeronSHB, Bhijn & Myr(deathride58) |
+| [Player Interaction](../space-station-14/player-interaction.md) | |
+| [Mapping](../space-station-14/mapping.md) | Emisse |
+| [Roleplay/Lore](../space-station-14/roleplay-lore.md) | Lank, KeronSHB, Vasilis |
+| [Round Flow](../space-station-14/round-flow.md) | Jezithyr, EmoGarbage, Tayrthan, KeronSHB, Bhijn & Myr(deathride58), AJCM |
+| [User Interface](../space-station-14/user-interface.md) | Jezithyr, EmoGarbage, AJCM, Julian, Bhijn & Myr(deathride58) |
### Departments
| Group | Members |
|-------|---------|
-| [Atmos](../space-station-14/areas/departments/atmos.md) | Jezithyr, KeronSHB, notafet(Partmedia) |
-| [Cargo/Salvage](../space-station-14/areas/departments/cargo-salvage.md) | |
-| [Command](../space-station-14/areas/departments/command.md) | KeronSHB, EmoGarbage, Vasilis |
-| [Engineering](../space-station-14/areas/departments/engineering.md) | Jezithyr, Julian, AJCM, KeronSHB |
-| [Medical](../space-station-14/areas/departments/medical.md) | Jezithyr, Vasilis, AJCM |
-| [Science](../space-station-14/areas/departments/science.md) | Jezithyr, EmoGarbage, AJCM, Tayrtahn |
-| [Security](../space-station-14/areas/departments/security.md) | Lank(LankLTE), KeronSHB |
-| [Service](../space-station-14/areas/departments/service.md) | AJCM, Tayrtahn, notafet(Partmedia) |
+| [Atmos](../space-station-14/departments/atmos.md) | Jezithyr, KeronSHB, notafet(Partmedia) |
+| [Cargo/Salvage](../space-station-14/departments/cargo-salvage.md) | |
+| [Command](../space-station-14/departments/command.md) | KeronSHB, EmoGarbage, Vasilis |
+| [Engineering](../space-station-14/departments/engineering.md) | Jezithyr, Julian, AJCM, KeronSHB |
+| [Medical](../space-station-14/departments/medical.md) | Jezithyr, Vasilis, AJCM |
+| [Science](../space-station-14/departments/science.md) | Jezithyr, EmoGarbage, AJCM, Tayrtahn |
+| [Security](../space-station-14/departments/security.md) | Lank(LankLTE), KeronSHB |
+| [Service](../space-station-14/departments/service.md) | AJCM, Tayrtahn, notafet(Partmedia) |
## For maintainers:
diff --git a/src/en/space-station-14/areas/core/accessibility.md b/src/en/space-station-14/accessibility.md
similarity index 100%
rename from src/en/space-station-14/areas/core/accessibility.md
rename to src/en/space-station-14/accessibility.md
diff --git a/src/en/space-station-14/areas/core/accessibility/guidelines.md b/src/en/space-station-14/accessibility/guidelines.md
similarity index 100%
rename from src/en/space-station-14/areas/core/accessibility/guidelines.md
rename to src/en/space-station-14/accessibility/guidelines.md
diff --git a/src/en/space-station-14/areas/core/accessibility/proposals/.gitkeep b/src/en/space-station-14/accessibility/proposals/.gitkeep
similarity index 100%
rename from src/en/space-station-14/areas/core/accessibility/proposals/.gitkeep
rename to src/en/space-station-14/accessibility/proposals/.gitkeep
diff --git a/src/en/space-station-14/areas/core/admin-tools.md b/src/en/space-station-14/admin-tools.md
similarity index 100%
rename from src/en/space-station-14/areas/core/admin-tools.md
rename to src/en/space-station-14/admin-tools.md
diff --git a/src/en/space-station-14/areas/core/admin-tools/guidelines.md b/src/en/space-station-14/admin-tools/guidelines.md
similarity index 100%
rename from src/en/space-station-14/areas/core/admin-tools/guidelines.md
rename to src/en/space-station-14/admin-tools/guidelines.md
diff --git a/src/en/space-station-14/areas/core/admin-tools/proposals/.gitkeep b/src/en/space-station-14/admin-tools/proposals/.gitkeep
similarity index 100%
rename from src/en/space-station-14/areas/core/admin-tools/proposals/.gitkeep
rename to src/en/space-station-14/admin-tools/proposals/.gitkeep
diff --git a/src/en/space-station-14/areas/departments/engineering/proposals/emogarbage-machine-upgrading-rework.md b/src/en/space-station-14/areas/departments/engineering/proposals/emogarbage-machine-upgrading-rework.md
deleted file mode 100644
index 0ea16bca9..000000000
--- a/src/en/space-station-14/areas/departments/engineering/proposals/emogarbage-machine-upgrading-rework.md
+++ /dev/null
@@ -1 +0,0 @@
-# Machine Upgrading Rework
diff --git a/src/en/space-station-14/areas/core/art.md b/src/en/space-station-14/art.md
similarity index 100%
rename from src/en/space-station-14/areas/core/art.md
rename to src/en/space-station-14/art.md
diff --git a/src/en/space-station-14/areas/core/art/displacement-maps.md b/src/en/space-station-14/art/displacement-maps.md
similarity index 100%
rename from src/en/space-station-14/areas/core/art/displacement-maps.md
rename to src/en/space-station-14/art/displacement-maps.md
diff --git a/src/en/space-station-14/areas/core/art/guidelines.md b/src/en/space-station-14/art/guidelines.md
similarity index 100%
rename from src/en/space-station-14/areas/core/art/guidelines.md
rename to src/en/space-station-14/art/guidelines.md
diff --git a/src/en/space-station-14/areas/core/art/proposals/.gitkeep b/src/en/space-station-14/art/proposals/.gitkeep
similarity index 100%
rename from src/en/space-station-14/areas/core/art/proposals/.gitkeep
rename to src/en/space-station-14/art/proposals/.gitkeep
diff --git a/src/en/space-station-14/areas/core/character-species/guidelines.md b/src/en/space-station-14/character-species/guidelines.md
similarity index 100%
rename from src/en/space-station-14/areas/core/character-species/guidelines.md
rename to src/en/space-station-14/character-species/guidelines.md
diff --git a/src/en/space-station-14/areas/core/character-species/proposals/.gitkeep b/src/en/space-station-14/character-species/proposals/.gitkeep
similarity index 100%
rename from src/en/space-station-14/areas/core/character-species/proposals/.gitkeep
rename to src/en/space-station-14/character-species/proposals/.gitkeep
diff --git a/src/en/space-station-14/areas/core/characters-species.md b/src/en/space-station-14/characters-species.md
similarity index 100%
rename from src/en/space-station-14/areas/core/characters-species.md
rename to src/en/space-station-14/characters-species.md
diff --git a/src/en/space-station-14/areas/core/combat.md b/src/en/space-station-14/combat.md
similarity index 100%
rename from src/en/space-station-14/areas/core/combat.md
rename to src/en/space-station-14/combat.md
diff --git a/src/en/space-station-14/areas/core/combat/guidelines.md b/src/en/space-station-14/combat/guidelines.md
similarity index 100%
rename from src/en/space-station-14/areas/core/combat/guidelines.md
rename to src/en/space-station-14/combat/guidelines.md
diff --git a/src/en/space-station-14/areas/core/combat/proposals/.gitkeep b/src/en/space-station-14/combat/proposals/.gitkeep
similarity index 100%
rename from src/en/space-station-14/areas/core/combat/proposals/.gitkeep
rename to src/en/space-station-14/combat/proposals/.gitkeep
diff --git a/src/en/space-station-14/design.md b/src/en/space-station-14/core-design.md
similarity index 94%
rename from src/en/space-station-14/design.md
rename to src/en/space-station-14/core-design.md
index fa1cc6b61..90a313714 100644
--- a/src/en/space-station-14/design.md
+++ b/src/en/space-station-14/core-design.md
@@ -1,7 +1,3 @@
-```admonish warning "Attention: WIP!"
-This section is actively under development and is not fully complete. Things may change!
-```
-
# Core Game Design
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.
@@ -19,7 +15,7 @@ Questions around Core Game Design should be directed towards the Design Group on
# Core Pillars
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.
-The pillars serve as guideposts for creating a cohesive design for SS14. Further detail about each can be found in: [Design Principles](design-principles.md).
+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).
## Chaotic
- 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.
diff --git a/src/en/space-station-14/core-design/departments.md b/src/en/space-station-14/core-design/departments.md
new file mode 100644
index 000000000..3dc8758ec
--- /dev/null
+++ b/src/en/space-station-14/core-design/departments.md
@@ -0,0 +1 @@
+# Departments
diff --git a/src/en/space-station-14/design-principles.md b/src/en/space-station-14/core-design/design-principles.md
similarity index 100%
rename from src/en/space-station-14/design-principles.md
rename to src/en/space-station-14/core-design/design-principles.md
diff --git a/src/en/space-station-14/areas/departments/medical/chemistry.md b/src/en/space-station-14/core-tech/chemistry.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/medical/chemistry.md
rename to src/en/space-station-14/core-tech/chemistry.md
diff --git a/src/en/space-station-14/areas/departments/medical/chemistry/metabolism.md b/src/en/space-station-14/core-tech/chemistry/metabolism.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/medical/chemistry/metabolism.md
rename to src/en/space-station-14/core-tech/chemistry/metabolism.md
diff --git a/src/en/space-station-14/areas/departments/medical/chemistry/reactions.md b/src/en/space-station-14/core-tech/chemistry/reactions.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/medical/chemistry/reactions.md
rename to src/en/space-station-14/core-tech/chemistry/reactions.md
diff --git a/src/en/space-station-14/areas/departments/medical/chemistry/reagents.md b/src/en/space-station-14/core-tech/chemistry/reagents.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/medical/chemistry/reagents.md
rename to src/en/space-station-14/core-tech/chemistry/reagents.md
diff --git a/src/en/space-station-14/areas/departments/medical/chemistry/solution-containers.md b/src/en/space-station-14/core-tech/chemistry/solution-containers.md
similarity index 99%
rename from src/en/space-station-14/areas/departments/medical/chemistry/solution-containers.md
rename to src/en/space-station-14/core-tech/chemistry/solution-containers.md
index 1f89c7846..64708e24d 100644
--- a/src/en/space-station-14/areas/departments/medical/chemistry/solution-containers.md
+++ b/src/en/space-station-14/core-tech/chemistry/solution-containers.md
@@ -61,4 +61,4 @@ Here is a full example of an entity with some Solutions:
Quantity: 20
maxVol: 20
- type: Drink
-```
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments/engineering/construction.md b/src/en/space-station-14/core-tech/construction.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/engineering/construction.md
rename to src/en/space-station-14/core-tech/construction.md
diff --git a/src/en/space-station-14/areas/core/combat/destructible.md b/src/en/space-station-14/core-tech/destructible.md
similarity index 99%
rename from src/en/space-station-14/areas/core/combat/destructible.md
rename to src/en/space-station-14/core-tech/destructible.md
index 96efe3def..7483f7fa3 100644
--- a/src/en/space-station-14/areas/core/combat/destructible.md
+++ b/src/en/space-station-14/core-tech/destructible.md
@@ -74,4 +74,4 @@ public partial class PlaySoundBehavior : IThresholdBehavior
SoundSystem.Play(Filter.Pvs(pos), Sound, pos, AudioHelpers.WithVariation(0.125f));
}
}
-```
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/departments/engineering/device-network.md b/src/en/space-station-14/core-tech/device-network.md
similarity index 99%
rename from src/en/space-station-14/areas/departments/engineering/device-network.md
rename to src/en/space-station-14/core-tech/device-network.md
index e063a975b..01085d1d0 100644
--- a/src/en/space-station-14/areas/departments/engineering/device-network.md
+++ b/src/en/space-station-14/core-tech/device-network.md
@@ -377,4 +377,4 @@ private void OnPacketReceived(Entity ent, ref DeviceNetw
}
}
}
-```
+```
\ No newline at end of file
diff --git a/src/en/space-station-14/core-tech/guidelines.md b/src/en/space-station-14/core-tech/guidelines.md
new file mode 100644
index 000000000..7a39e41cb
--- /dev/null
+++ b/src/en/space-station-14/core-tech/guidelines.md
@@ -0,0 +1 @@
+# PR Guidelines
diff --git a/src/en/space-station-14/areas/departments/engineering/node-networks.md b/src/en/space-station-14/core-tech/node-networks.md
similarity index 99%
rename from src/en/space-station-14/areas/departments/engineering/node-networks.md
rename to src/en/space-station-14/core-tech/node-networks.md
index 3f54c1d89..ae789da5c 100644
--- a/src/en/space-station-14/areas/departments/engineering/node-networks.md
+++ b/src/en/space-station-14/core-tech/node-networks.md
@@ -72,4 +72,4 @@ Multiple `NodeGroupID`s may be mapped to one `NodeGroup` implementation.
+ `Apc`: APC Extension Cables -> `ApcNetNodeGroup`
+ `MVPower`: MV Wire -> `PowerNetNodeGroup`
-+ `HVPower`: HV Wire -> `PowerNetNodeGroup`
++ `HVPower`: HV Wire -> `PowerNetNodeGroup`
\ No newline at end of file
diff --git a/src/en/space-station-14/areas/core/round-flow/npcs.md b/src/en/space-station-14/core-tech/npcs.md
similarity index 100%
rename from src/en/space-station-14/areas/core/round-flow/npcs.md
rename to src/en/space-station-14/core-tech/npcs.md
diff --git a/src/en/space-station-14/areas/departments.md b/src/en/space-station-14/departments.md
similarity index 100%
rename from src/en/space-station-14/areas/departments.md
rename to src/en/space-station-14/departments.md
diff --git a/src/en/space-station-14/areas/departments/atmos.md b/src/en/space-station-14/departments/atmos.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/atmos.md
rename to src/en/space-station-14/departments/atmos.md
diff --git a/src/en/space-station-14/areas/core/player-interaction/guidelines.md b/src/en/space-station-14/departments/atmos/guidelines.md
similarity index 100%
rename from src/en/space-station-14/areas/core/player-interaction/guidelines.md
rename to src/en/space-station-14/departments/atmos/guidelines.md
diff --git a/src/en/space-station-14/areas/departments/atmos/proposals/atmos-rework.md b/src/en/space-station-14/departments/atmos/proposals/atmos-rework.md
similarity index 97%
rename from src/en/space-station-14/areas/departments/atmos/proposals/atmos-rework.md
rename to src/en/space-station-14/departments/atmos/proposals/atmos-rework.md
index 0458dde54..c5566664f 100644
--- a/src/en/space-station-14/areas/departments/atmos/proposals/atmos-rework.md
+++ b/src/en/space-station-14/departments/atmos/proposals/atmos-rework.md
@@ -15,7 +15,7 @@ Most atmos players currently agree that atmos is not very fun to play, for some
2. Atmos can't actually rectify atmos problems in a reasonable amount of time. For example, if there actually is a plasma leak, scrubbers typically work too slowly resulting in the plasma inevitably being lit before it can be cleaned up.
-3. Atmos techs don't play with the rest of the station, preferring to isolate themselves to produce a funny green gas that is only particularly useful for shuttle bombing. Mechanics like this violate the [fundamental design principles](../../../../design.md). While these mechanics shouldn't be removed per-se, more focus should be given to mechanics that increase interactions with the station, like making sure the air is breathable and well-heated.
+3. Atmos techs don't play with the rest of the station, preferring to isolate themselves to produce a funny green gas that is only particularly useful for shuttle bombing. Mechanics like this violate the [fundamental design principles](../../../core-design.md). While these mechanics shouldn't be removed per-se, more focus should be given to mechanics that increase interactions with the station, like making sure the air is breathable and well-heated.
## Proposal
diff --git a/src/en/space-station-14/areas/departments/cargo-salvage.md b/src/en/space-station-14/departments/cargo-salvage.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/cargo-salvage.md
rename to src/en/space-station-14/departments/cargo-salvage.md
diff --git a/src/en/space-station-14/areas/core/roleplay-lore/guidelines.md b/src/en/space-station-14/departments/cargo-salvage/guidelines.md
similarity index 100%
rename from src/en/space-station-14/areas/core/roleplay-lore/guidelines.md
rename to src/en/space-station-14/departments/cargo-salvage/guidelines.md
diff --git a/src/en/space-station-14/areas/core/mapping/proposals/.gitkeep b/src/en/space-station-14/departments/cargo-salvage/proposals/.gitkeep
similarity index 100%
rename from src/en/space-station-14/areas/core/mapping/proposals/.gitkeep
rename to src/en/space-station-14/departments/cargo-salvage/proposals/.gitkeep
diff --git a/src/en/space-station-14/areas/departments/command.md b/src/en/space-station-14/departments/command.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/command.md
rename to src/en/space-station-14/departments/command.md
diff --git a/src/en/space-station-14/areas/core/round-flow/guidelines.md b/src/en/space-station-14/departments/command/guidelines.md
similarity index 100%
rename from src/en/space-station-14/areas/core/round-flow/guidelines.md
rename to src/en/space-station-14/departments/command/guidelines.md
diff --git a/src/en/space-station-14/areas/core/roleplay-lore/proposals/.gitkeep b/src/en/space-station-14/departments/command/proposals/.gitkeep
similarity index 100%
rename from src/en/space-station-14/areas/core/roleplay-lore/proposals/.gitkeep
rename to src/en/space-station-14/departments/command/proposals/.gitkeep
diff --git a/src/en/space-station-14/areas/departments/engineering.md b/src/en/space-station-14/departments/engineering.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/engineering.md
rename to src/en/space-station-14/departments/engineering.md
diff --git a/src/en/space-station-14/areas/core/user-interface/guidelines.md b/src/en/space-station-14/departments/engineering/guidelines.md
similarity index 100%
rename from src/en/space-station-14/areas/core/user-interface/guidelines.md
rename to src/en/space-station-14/departments/engineering/guidelines.md
diff --git a/src/en/space-station-14/areas/departments/engineering/pow3r.md b/src/en/space-station-14/departments/engineering/pow3r.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/engineering/pow3r.md
rename to src/en/space-station-14/departments/engineering/pow3r.md
diff --git a/src/en/space-station-14/areas/departments/engineering/proposals/engine-containment.md b/src/en/space-station-14/departments/engineering/proposals/engine-containment.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/engineering/proposals/engine-containment.md
rename to src/en/space-station-14/departments/engineering/proposals/engine-containment.md
diff --git a/src/en/space-station-14/areas/departments/engineering/proposals/machine-upgrading-rework.md b/src/en/space-station-14/departments/engineering/proposals/machine-upgrading-rework.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/engineering/proposals/machine-upgrading-rework.md
rename to src/en/space-station-14/departments/engineering/proposals/machine-upgrading-rework.md
diff --git a/src/en/space-station-14/areas/departments/engineering/proposals/power-generation.md b/src/en/space-station-14/departments/engineering/proposals/power-generation.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/engineering/proposals/power-generation.md
rename to src/en/space-station-14/departments/engineering/proposals/power-generation.md
diff --git a/src/en/space-station-14/areas/departments/engineering/proposals/signaller-rework.md b/src/en/space-station-14/departments/engineering/proposals/signaller-rework.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/engineering/proposals/signaller-rework.md
rename to src/en/space-station-14/departments/engineering/proposals/signaller-rework.md
diff --git a/src/en/space-station-14/areas/departments/medical.md b/src/en/space-station-14/departments/medical.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/medical.md
rename to src/en/space-station-14/departments/medical.md
diff --git a/src/en/space-station-14/areas/departments/atmos/guidelines.md b/src/en/space-station-14/departments/medical/guidelines.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/atmos/guidelines.md
rename to src/en/space-station-14/departments/medical/guidelines.md
diff --git a/src/en/space-station-14/areas/departments/cargo-salvage/proposals/.gitkeep b/src/en/space-station-14/departments/medical/proposals/.gitkeep
similarity index 100%
rename from src/en/space-station-14/areas/departments/cargo-salvage/proposals/.gitkeep
rename to src/en/space-station-14/departments/medical/proposals/.gitkeep
diff --git a/src/en/space-station-14/areas/departments/science.md b/src/en/space-station-14/departments/science.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/science.md
rename to src/en/space-station-14/departments/science.md
diff --git a/src/en/space-station-14/areas/departments/science/anomaly-cores.md b/src/en/space-station-14/departments/science/anomaly-cores.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/science/anomaly-cores.md
rename to src/en/space-station-14/departments/science/anomaly-cores.md
diff --git a/src/en/space-station-14/areas/departments/cargo-salvage/guidelines.md b/src/en/space-station-14/departments/science/guidelines.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/cargo-salvage/guidelines.md
rename to src/en/space-station-14/departments/science/guidelines.md
diff --git a/src/en/space-station-14/areas/departments/science/proposals/xenoarch-redux.md b/src/en/space-station-14/departments/science/proposals/xenoarch-redux.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/science/proposals/xenoarch-redux.md
rename to src/en/space-station-14/departments/science/proposals/xenoarch-redux.md
diff --git a/src/en/space-station-14/areas/departments/security.md b/src/en/space-station-14/departments/security.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/security.md
rename to src/en/space-station-14/departments/security.md
diff --git a/src/en/space-station-14/areas/departments/command/guidelines.md b/src/en/space-station-14/departments/security/guidelines.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/command/guidelines.md
rename to src/en/space-station-14/departments/security/guidelines.md
diff --git a/src/en/space-station-14/areas/departments/security/proposals/genpop-prisoners.md b/src/en/space-station-14/departments/security/proposals/genpop-prisoners.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/security/proposals/genpop-prisoners.md
rename to src/en/space-station-14/departments/security/proposals/genpop-prisoners.md
diff --git a/src/en/space-station-14/areas/departments/service.md b/src/en/space-station-14/departments/service.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/service.md
rename to src/en/space-station-14/departments/service.md
diff --git a/src/en/space-station-14/areas/departments/engineering/guidelines.md b/src/en/space-station-14/departments/service/guidelines.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/engineering/guidelines.md
rename to src/en/space-station-14/departments/service/guidelines.md
diff --git a/src/en/space-station-14/areas/departments/service/proposals/plant-genetics.md b/src/en/space-station-14/departments/service/proposals/plant-genetics.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/service/proposals/plant-genetics.md
rename to src/en/space-station-14/departments/service/proposals/plant-genetics.md
diff --git a/src/en/space-station-14/areas/core/mapping.md b/src/en/space-station-14/mapping.md
similarity index 100%
rename from src/en/space-station-14/areas/core/mapping.md
rename to src/en/space-station-14/mapping.md
diff --git a/src/en/space-station-14/areas/core/mapping/dungeons.md b/src/en/space-station-14/mapping/dungeons.md
similarity index 97%
rename from src/en/space-station-14/areas/core/mapping/dungeons.md
rename to src/en/space-station-14/mapping/dungeons.md
index ae33efed7..8f6e5a6ce 100644
--- a/src/en/space-station-14/areas/core/mapping/dungeons.md
+++ b/src/en/space-station-14/mapping/dungeons.md
@@ -52,7 +52,7 @@ Making new rooms requires a saved map file and prototypes created specifying the
There is a template that can be used below. **Note that there is no limit to size or rooms.**
-[dungeon_template.yml](../../../../assets/misc/dungeon_template.yml)
+[dungeon_template.yml](../../assets/misc/dungeon_template.yml)
## Mapping suggestions
diff --git a/src/en/space-station-14/areas/core/mapping/guidelines.md b/src/en/space-station-14/mapping/guidelines.md
similarity index 97%
rename from src/en/space-station-14/areas/core/mapping/guidelines.md
rename to src/en/space-station-14/mapping/guidelines.md
index d077808fa..75c5e302b 100644
--- a/src/en/space-station-14/areas/core/mapping/guidelines.md
+++ b/src/en/space-station-14/mapping/guidelines.md
@@ -14,24 +14,24 @@ Don't do any of these. They make for bad looking/feeling maps.
## Ultra-wide hallways
So the thing about hallways is that they're empty.
-![oversized-hallway.png](../../../../assets/images/mapping/oversized-hallway.png)
+![oversized-hallway.png](../../assets/images/mapping/oversized-hallway.png)
This looks and feels bad to play in, with a very large amount of blank space visually.
### Ways to fix
#### Convert to a parkway
Filling the visual emptiness with plantlife or other decoratives helps significantly. This shouldn't be overdone, though, and it's preferrable to simply use smaller hallways.
-![parkway-example.png](../../../../assets/images/mapping/parkway-example.png)
+![parkway-example.png](../../assets/images/mapping/parkway-example.png)
## Abdundance of silver/gold tiles
To put it simply they look terrible, especially combined with decals, and should be used only in extremely specific situations.
-![silver-tiles-hell.png](../../../../assets/images/mapping/silver-tiles-hell.png)
+![silver-tiles-hell.png](../../assets/images/mapping/silver-tiles-hell.png)
### Ways to fix
#### Just change the theme
If you're using them to line a "rich feeling" room, say, the HoP's office, opt for instead focusing on a home-y feeling, with woods/etc. Most of the station simply does not have this feel and it'll make them seem exceptional.
-![silver-tiles-hell-except-good.png](../../../../assets/images/mapping/silver-tiles-hell-except-good.png)
+![silver-tiles-hell-except-good.png](../../assets/images/mapping/silver-tiles-hell-except-good.png)
# Mapping Checklist
diff --git a/src/en/space-station-14/areas/core/mapping/guides/general-guide.md b/src/en/space-station-14/mapping/guides/general-guide.md
similarity index 98%
rename from src/en/space-station-14/areas/core/mapping/guides/general-guide.md
rename to src/en/space-station-14/mapping/guides/general-guide.md
index cdd476457..eac747615 100644
--- a/src/en/space-station-14/areas/core/mapping/guides/general-guide.md
+++ b/src/en/space-station-14/mapping/guides/general-guide.md
@@ -33,7 +33,7 @@ To test the map:
# Setup
## With Development Environment
-A [development environment](../../../../../general-development/setup/setting-up-a-development-environment.md) and [Git installation](../../../../../general-development/setup/git-for-the-ss14-developer.md) are strongly recommended, so that you can keep your local mapping server up to date and submit [pull requests](../../../../../general-development/codebase-info/pull-request-guidelines.md).
+A [development environment](../../../general-development/setup/setting-up-a-development-environment.md) and [Git installation](../../../general-development/setup/git-for-the-ss14-developer.md) are strongly recommended, so that you can keep your local mapping server up to date and submit [pull requests](../../../general-development/codebase-info/pull-request-guidelines.md).
### Tools Build
If you are using a development enviroment instead of just hosting a local server, make sure to use Tools instead of Debug/DebugOpt mode. This is because Debug adds artificial lag (making mapping unpleasant) and crashes more (having more assertions enabled).
@@ -46,7 +46,7 @@ dotnet run --project Content.Client --configuration Tools
```
If you are using an IDE, there will be some other way of setting the configuration. For example, in VS there is simply a dropdown menu:
-![mapping-release-dropdown.png](../../../../../assets/images/mapping/mapping-release-dropdown.png)
+![mapping-release-dropdown.png](../../../assets/images/mapping/mapping-release-dropdown.png)
## Without Development Environment
If you choose not to do this, you will need to download a [recent server build](https://central.spacestation14.io/builds/wizards/builds.html).
diff --git a/src/en/space-station-14/areas/departments/command/proposals/.gitkeep b/src/en/space-station-14/mapping/proposals/.gitkeep
similarity index 100%
rename from src/en/space-station-14/areas/departments/command/proposals/.gitkeep
rename to src/en/space-station-14/mapping/proposals/.gitkeep
diff --git a/src/en/space-station-14/areas/core/player-interaction.md b/src/en/space-station-14/player-interaction.md
similarity index 100%
rename from src/en/space-station-14/areas/core/player-interaction.md
rename to src/en/space-station-14/player-interaction.md
diff --git a/src/en/space-station-14/areas/core/player-interaction/cartridge-loaders.md b/src/en/space-station-14/player-interaction/cartridge-loaders.md
similarity index 100%
rename from src/en/space-station-14/areas/core/player-interaction/cartridge-loaders.md
rename to src/en/space-station-14/player-interaction/cartridge-loaders.md
diff --git a/src/en/space-station-14/areas/core/player-interaction/grid-inventory.md b/src/en/space-station-14/player-interaction/grid-inventory.md
similarity index 96%
rename from src/en/space-station-14/areas/core/player-interaction/grid-inventory.md
rename to src/en/space-station-14/player-interaction/grid-inventory.md
index c576ede2b..618dbec08 100644
--- a/src/en/space-station-14/areas/core/player-interaction/grid-inventory.md
+++ b/src/en/space-station-14/player-interaction/grid-inventory.md
@@ -37,7 +37,7 @@ It should never feel sprawling or overwhelming or like you're scanning your scre
Our solution? A to-scale HUD element that can represent uniquely shaped item's as well as display the size of things in an immersive and immediately understandable way.
-![](../../../../assets/images/grid-inventory/in-game.png)
+![](../../assets/images/grid-inventory/in-game.png)
### Items
@@ -47,14 +47,14 @@ This is just the shape the item takes up in the grid and it additionally serves
Rather than tiny items having a weight value of 1, they simply take up a single square.
Items would have reasonable default sizes inferred from the current weight values of items with an optional specifier for other custom shapes.
-![](../../../../assets/images/grid-inventory/shape-examples.png)
+![](../../assets/images/grid-inventory/shape-examples.png)
Inside of the inventory, you'd be able to manually move around and rotate items, allowing gaps to be filled and space optimized with proper planning.
You'd also be able to intuit how much of the inventory an item fills from a simple glance, since the volume is of the container is represented visually.
### Storage
-![](../../../../assets/images/grid-inventory/grid-example.png)
+![](../../assets/images/grid-inventory/grid-example.png)
For the most part, storages exist as literal translations of the current values.
A 28 capacity simply becomes a 7x4 box.
diff --git a/src/en/space-station-14/areas/departments/medical/guidelines.md b/src/en/space-station-14/player-interaction/guidelines.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/medical/guidelines.md
rename to src/en/space-station-14/player-interaction/guidelines.md
diff --git a/src/en/space-station-14/areas/core/player-interaction/proposals/pda-messaging.md b/src/en/space-station-14/player-interaction/proposals/pda-messaging.md
similarity index 100%
rename from src/en/space-station-14/areas/core/player-interaction/proposals/pda-messaging.md
rename to src/en/space-station-14/player-interaction/proposals/pda-messaging.md
diff --git a/src/en/space-station-14/areas/core/roleplay-lore.md b/src/en/space-station-14/roleplay-lore.md
similarity index 100%
rename from src/en/space-station-14/areas/core/roleplay-lore.md
rename to src/en/space-station-14/roleplay-lore.md
diff --git a/src/en/space-station-14/areas/departments/science/guidelines.md b/src/en/space-station-14/roleplay-lore/guidelines.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/science/guidelines.md
rename to src/en/space-station-14/roleplay-lore/guidelines.md
diff --git a/src/en/space-station-14/areas/departments/medical/proposals/.gitkeep b/src/en/space-station-14/roleplay-lore/proposals/.gitkeep
similarity index 100%
rename from src/en/space-station-14/areas/departments/medical/proposals/.gitkeep
rename to src/en/space-station-14/roleplay-lore/proposals/.gitkeep
diff --git a/src/en/space-station-14/areas/core/round-flow.md b/src/en/space-station-14/round-flow.md
similarity index 100%
rename from src/en/space-station-14/areas/core/round-flow.md
rename to src/en/space-station-14/round-flow.md
diff --git a/src/en/space-station-14/areas/core/round-flow/antagonists.md b/src/en/space-station-14/round-flow/antagonists.md
similarity index 100%
rename from src/en/space-station-14/areas/core/round-flow/antagonists.md
rename to src/en/space-station-14/round-flow/antagonists.md
diff --git a/src/en/space-station-14/areas/core/round-flow/antagonists/exterminator.md b/src/en/space-station-14/round-flow/antagonists/exterminator.md
similarity index 100%
rename from src/en/space-station-14/areas/core/round-flow/antagonists/exterminator.md
rename to src/en/space-station-14/round-flow/antagonists/exterminator.md
diff --git a/src/en/space-station-14/areas/core/round-flow/antagonists/thief.md b/src/en/space-station-14/round-flow/antagonists/thief.md
similarity index 100%
rename from src/en/space-station-14/areas/core/round-flow/antagonists/thief.md
rename to src/en/space-station-14/round-flow/antagonists/thief.md
diff --git a/src/en/space-station-14/areas/departments/security/guidelines.md b/src/en/space-station-14/round-flow/guidelines.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/security/guidelines.md
rename to src/en/space-station-14/round-flow/guidelines.md
diff --git a/src/en/space-station-14/areas/core/round-flow/proposals/cleanup-crew-gamemode.md b/src/en/space-station-14/round-flow/proposals/cleanup-crew-gamemode.md
similarity index 100%
rename from src/en/space-station-14/areas/core/round-flow/proposals/cleanup-crew-gamemode.md
rename to src/en/space-station-14/round-flow/proposals/cleanup-crew-gamemode.md
diff --git a/src/en/space-station-14/areas/core/round-flow/proposals/game-director.md b/src/en/space-station-14/round-flow/proposals/game-director.md
similarity index 100%
rename from src/en/space-station-14/areas/core/round-flow/proposals/game-director.md
rename to src/en/space-station-14/round-flow/proposals/game-director.md
diff --git a/src/en/space-station-14/areas/core/round-flow/proposals/pizza-delivery-critter.md b/src/en/space-station-14/round-flow/proposals/pizza-delivery-critter.md
similarity index 100%
rename from src/en/space-station-14/areas/core/round-flow/proposals/pizza-delivery-critter.md
rename to src/en/space-station-14/round-flow/proposals/pizza-delivery-critter.md
diff --git a/src/en/space-station-14/areas/core/round-flow/proposals/rogue-drones.md b/src/en/space-station-14/round-flow/proposals/rogue-drones.md
similarity index 100%
rename from src/en/space-station-14/areas/core/round-flow/proposals/rogue-drones.md
rename to src/en/space-station-14/round-flow/proposals/rogue-drones.md
diff --git a/src/en/space-station-14/areas/core/round-flow/proposals/turf-war.md b/src/en/space-station-14/round-flow/proposals/turf-war.md
similarity index 100%
rename from src/en/space-station-14/areas/core/round-flow/proposals/turf-war.md
rename to src/en/space-station-14/round-flow/proposals/turf-war.md
diff --git a/src/en/space-station-14/areas/core/user-interface.md b/src/en/space-station-14/user-interface.md
similarity index 100%
rename from src/en/space-station-14/areas/core/user-interface.md
rename to src/en/space-station-14/user-interface.md
diff --git a/src/en/space-station-14/areas/departments/service/guidelines.md b/src/en/space-station-14/user-interface/guidelines.md
similarity index 100%
rename from src/en/space-station-14/areas/departments/service/guidelines.md
rename to src/en/space-station-14/user-interface/guidelines.md
diff --git a/src/en/space-station-14/areas/core/user-interface/proposals/statpanels.md b/src/en/space-station-14/user-interface/proposals/statpanels.md
similarity index 100%
rename from src/en/space-station-14/areas/core/user-interface/proposals/statpanels.md
rename to src/en/space-station-14/user-interface/proposals/statpanels.md
diff --git a/src/en/ss14-by-example/introduction-to-ss14-by-example.md b/src/en/ss14-by-example/introduction-to-ss14-by-example.md
index d0af76b44..27407080e 100644
--- a/src/en/ss14-by-example/introduction-to-ss14-by-example.md
+++ b/src/en/ss14-by-example/introduction-to-ss14-by-example.md
@@ -6,6 +6,6 @@ SS14 By Example is a knowledgebase for figuring out how to do a lot of simple ta
If you're coming here from BYOND or SS13, hello! These docs are written with that audience in mind, and it tries to translate some broad topics from SS13 into SS14 and Robust Toolbox.
-SS14 By Example will not cover extending content that already exists in SS14, such as [construction](../space-station-14/areas/departments/engineering/construction.md), [chemistry](../space-station-14/areas/departments/medical/chemistry.md), body system, or botany. These should either be evident from the code, or are covered in **Content Documentation**. You can see the topics that will be covered in the sidebar, or at the bottom of this page.
+SS14 By Example will not cover extending content that already exists in SS14, such as [construction](../space-station-14/core-tech/construction.md), [chemistry](../space-station-14/core-tech/chemistry.md), body system, or botany. These should either be evident from the code, or are covered in **Content Documentation**. You can see the topics that will be covered in the sidebar, or at the bottom of this page.
SS14 By Example will also not cover [basic setup](../general-development/setup.md) or cover any [codebase info](../general-development/codebase-info.md) like conventions or common nomenclature, as these have their own documentation elsewhere on this site.
\ No newline at end of file
diff --git a/src/en/templates-docs/department-design-template.md b/src/en/templates-docs/department-design-template.md
new file mode 100644
index 000000000..9b8c66a6b
--- /dev/null
+++ b/src/en/templates-docs/department-design-template.md
@@ -0,0 +1,39 @@
+# Department Name
+> (Optional) A short phrase or joke that embodies the concept of this department
+
+## Concept
+> A high-level conceptual overview of what this department does. This is generally 1-2 paragraphs and should reflect a high level view of what this department brings to the player and the game.
+
+## Player Story
+> 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.
+
+## Design Pillars
+> 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.
+
+> 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.
+
+> 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.
+
+### Pillar_1:
+ > Breif Pillar Description
+
+ ### Pillar_2:
+ > Breif Pillar Description
+
+## Objectives
+> 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?
+
+## Progression
+> 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?
+
+## Flow
+> 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?
+
+## Mechanics
+> What major mechanics does this department use and how are they connected to this department.
+
+### Mechanic_Placeholder1
+> 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.
+
+### Mechanic_Placeholder2 (Not Implemented Yet)
+> Mechanics that are unimplemented should be marked with (Not Implmented Yet) and should link the associated design proposal if it exists.
\ No newline at end of file
diff --git a/src/index.md b/src/index.md
index 0d04b48b8..75cf78cff 100644
--- a/src/index.md
+++ b/src/index.md
@@ -21,8 +21,8 @@ If you would like to make contributions to this documentation site, it's hosted
- [:question: How do I code?](en/general-development/setup/howdoicode.md)
- [:package: Setting up the Dev Environment](en/general-development/setup/setting-up-a-development-environment.md)
-- [:page_with_curl: Core Game Design](en/space-station-14/design.md)
-- [:world_map: Mapping](en/space-station-14/areas/core/mapping.md)
+- [:page_with_curl: Core Game Design](en/space-station-14/core-design.md)
+- [:world_map: Mapping](en/space-station-14/mapping.md)
- [:chart_with_upwards_trend: Git for the SS14 Developer](en/general-development/setup/git-for-the-ss14-developer.md)
From 446a45d84207e5fd7602df4a1e210a57b32a3eb6 Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Tue, 30 Apr 2024 21:51:41 +0200
Subject: [PATCH 31/80] Update title for RT bundle update
---
src/SUMMARY.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index cc3af6f06..7c250475a 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -93,7 +93,7 @@ Robust Toolbox
- [MIDI](en/robust-toolbox/midi.md)
- [Automatic Client Zip (ACZ)](en/robust-toolbox/acz.md)
- [Asset Packaging](en/robust-toolbox/asset-packaging.md)
-- [Publishing a new version](en/robust-toolbox/publishing-robusttoolbox.md)
+- [Publishing a new Robust Toolbox Version](en/robust-toolbox/publishing-robusttoolbox.md)
Space Station 14
================
From cf3e50f0c81e8d8f4c6ee8cca8913428b8194ad6 Mon Sep 17 00:00:00 2001
From: deltanedas <39013340+deltanedas@users.noreply.github.com>
Date: Tue, 30 Apr 2024 21:44:05 +0000
Subject: [PATCH 32/80] pai expansion slots proposal (#183)
---
src/SUMMARY.md | 1 +
.../proposals/pai-expansion-slots.md | 32 +++++++++++++++++++
2 files changed, 33 insertions(+)
create mode 100644 src/en/space-station-14/player-interaction/proposals/pai-expansion-slots.md
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 7c250475a..2cc798dc9 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -162,6 +162,7 @@ Space Station 14
- [Grid Inventory](en/space-station-14/player-interaction/grid-inventory.md)
- [Proposals]()
+ - [PAI Expansion Slots](en/space-station-14/areas/core/player-interaction/proposals/pai-expansion-slots.md)
- [Roleplay/Lore](en/space-station-14/roleplay-lore.md)
- [PR Guidelines](en/space-station-14/roleplay-lore/guidelines.md)
diff --git a/src/en/space-station-14/player-interaction/proposals/pai-expansion-slots.md b/src/en/space-station-14/player-interaction/proposals/pai-expansion-slots.md
new file mode 100644
index 000000000..5c95abe15
--- /dev/null
+++ b/src/en/space-station-14/player-interaction/proposals/pai-expansion-slots.md
@@ -0,0 +1,32 @@
+# PAI Expansion Slots
+
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| deltanedas | :warning: wip | TBD |
+
+## Overview
+
+This proposal adds an expansion slot to pAIs.
+Certain computer boards can be inserted as expansions which let the pAI (but not anyone else) interact with the world.
+Once a pai has an expansion installed **it cannot be removed** so you cannot hotswap boards to let a single pAI do everything.
+
+## Background
+
+Right now pAIs don't have much to do, especially if they have no midi library built up.
+
+With this pais can do more interesting things like:
+- Detective's pai watching over cams
+- Scientist's pai unlocking techs on the go
+- Captain's pai making announcements about who is valid
+
+However since the pAI on its own is not special the user has to go and find a board to use, creating RP scenarios.
+
+This creates more depth to a glorified jukebox, and owners can now choose an expansion wisely.
+
+## Implementation
+
+PAIs get a maintenance panel which will allow inserting an expansion board.
+
+A PaiExpansionComponent has a comp registry of things to add to the pAI once installed.
+
+This would also allow implementing things like a protolathe pai that you insert materials into then ask to make things, or an id console pai that copies accesses itself. It would "just" be itemslots and the component but without ActivatableUI.
From 3cb4bc3ae717a356843025e63a91c1a489987805 Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Wed, 1 May 2024 01:18:19 +0300
Subject: [PATCH 33/80] Discord bot docs maintenance (#211)
Add python requirement, fix grammar, fix other shit in the discord bot docs
---
src/en/server-hosting/setting-up-redbot.md | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/en/server-hosting/setting-up-redbot.md b/src/en/server-hosting/setting-up-redbot.md
index 825ce722a..8b362470f 100644
--- a/src/en/server-hosting/setting-up-redbot.md
+++ b/src/en/server-hosting/setting-up-redbot.md
@@ -8,6 +8,10 @@ Luckily for you, this is easy to set up with the help of the [Red Discord Bot](h
We only provide support for the official wizard-cogs in the #hosting channel on the discord, Support for Red itself or other cogs is not provided by us, please get support in the official RedBot Discord or the appropriate cog developer.
```
+```admonish warning
+Most of our cogs require a minimum of python 3.11, please ensure you have this version before asking for support.
+```
+
## Setup
1. Follow the [Red Documenation](https://docs.discord.red/en/stable/install_guides/index.html) on how to install and start the Base Red bot. Note that like an SS14 server. You need a computer that will stay turned on for your bot to function.
2. If you have not already, give [Red's Getting started](https://docs.discord.red/en/stable/getting_started.html#getting-started) page a read.
@@ -21,14 +25,17 @@ Add the wizard-cogs repository
Install the cog of choice, check out the GitHub link to see your options
[p]cog install wizard-cogs
+
+Load the cog
+[p]load
```
-```admonish note title="Psss"
+```admonish note title="Hints"
Looking for other interesting cogs? Check out the [Redbot Cog index](https://index.discord.red/). Like stated above we don't provide support for these cogs.
-```
-```admonish note title="Psss Combo 2"
+
Not an English server? Some cogs have translations, You can change this with ```[p]set locale ```. Our cogs don't support other languages than English currently.
```
+
Now you are ready, please be sure to check the [Wizard-Cogs Github](https://github.com/space-wizards/wizard-cogs) in case any new cogs have been added.
@@ -99,9 +106,9 @@ Once it's merged and confirmed stable I will update this documentation with all
### GitHub Integration
Yet to be ported to redbot. You can use a [github webhook](https://gist.github.com/jagrosh/5b1761213e33fc5b54ec7f6379034a22) in the meantime.
-### Autoresponder (WYCI, Nanotrashen Block Game, Based)
+### Autoresponder (WYCI, Nanotrasen Block Game, Based)
![why](../assets/images/discord/autoresponder-example.png)
```[p]cog install wizard-cogs autoresponder```
-Why... (Responds to users saying "Something when" with "When you code it", "Tetris" with "Nanotrashen Block Game" and "Based" with "Based on what". This is an inside joke inside Space Station 14 communities)
+Why... (Responds to users saying "Something when" with "When you code it", "Tetris" with "Nanotrasen Block Game" and "Based" with "Based on what". This is an inside joke inside Space Station 14 communities)
From 0bb4dca8015ad42062efb2270a648753c5d03502 Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Wed, 1 May 2024 00:33:28 +0200
Subject: [PATCH 34/80] Fix skill issue
---
src/en/server-hosting/setting-up-redbot.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/en/server-hosting/setting-up-redbot.md b/src/en/server-hosting/setting-up-redbot.md
index 8b362470f..555653922 100644
--- a/src/en/server-hosting/setting-up-redbot.md
+++ b/src/en/server-hosting/setting-up-redbot.md
@@ -92,7 +92,7 @@ While it's not specificly a bot feature, I thought I might as well throw it in h
1. Make a discord webhook in the channel you want the pings to arrive in. You can make one by clicking on the cogwheel in the channel > Integrations > Webhooks. Once done copy the URL
2. Set the following [CCVars](https://docs.spacestation14.com/en/general-development/tips/config-file-reference.html) in your config
```
-discord.ahelp =
+discord.ahelp_webhook =
discord.round_update_webhook =
discord.round_end_role =
```
From 744826230a48ffe4bcc69f98c6ac2ff47f857f59 Mon Sep 17 00:00:00 2001
From: Kevin Zheng
Date: Fri, 3 May 2024 06:26:52 -0800
Subject: [PATCH 35/80] Initial fast spacing proposal (#190)
---
.../atmos/proposals/atmos-rework.md | 25 +++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/src/en/space-station-14/departments/atmos/proposals/atmos-rework.md b/src/en/space-station-14/departments/atmos/proposals/atmos-rework.md
index c5566664f..149f78315 100644
--- a/src/en/space-station-14/departments/atmos/proposals/atmos-rework.md
+++ b/src/en/space-station-14/departments/atmos/proposals/atmos-rework.md
@@ -57,6 +57,31 @@ These principles suggest changes to devices:
- ~~**Make heaters and freezers thermodynamically sound.** Keeping a station properly heated or cooled is actually a substantial real-life problem. Because of the existence of generators like the TEG, keeping things thermodynamically balanced is also a great way to prevent infinite power hacks.~~ (implemented as a part of [atmos speedup](https://github.com/space-wizards/space-station-14/pull/22372))
+### Fast(er) Spacing
+
+**Spacing should be fast(er).** Here, "fast(er) spacing" means `0.05 < atmos.mmos_spacing_speed < 1.0`.
+
+At the time of writing, the current "slow" spacing has `atmos.mmos_spacing_speed = 0.05`. A `atmos.mmos_spacing_speed = 1.0` corresponds to the old "instant spacing behavior". This design doc advocates for spacing that is faster than what it is now, but not as fast as it used to be.
+
+This should come with the necessary bits to make it work well in a balanced way, for example:
+
+- Single tile double firelocks for special zones on the station that should be isolated from each other
+- Mitigations for mass spacing like hardsuit puncturing (see below)
+
+#### Arguments For (Pros)
+
+- **Makes more intuitive sense.** Recent events has taught us that a door plug blowout even in Earth's atmosphere is quite serious. In space spacing should be fast because that's what makes more intuitive sense. It ruins your immersion if somebody can just casually waltz into space and surive just fine for two minutes.
+
+- **Is better for [Intuitive and Inter-Connected Simulation](https://docs.spacestation14.com/en/space-station-14/core-design.html#intuitive-and-inter-connected-simulation).** Spacing should have serious consequences that that create engaging gameplay/decisions while still being intuitive enough to learn and create new emergent gameplay opportunities, e.g. "I can't go through this hallway because it's spaced, so I have to think of a way to survive by taking a detour through these maints." Spacing should be treated as a serious problem.
+
+- **Is [more fun](https://docs.spacestation14.com/en/space-station-14/core-design.html#seriously-silly).** You should be able to be ejected out of the station at high speed due to the atmos canon effect.
+
+- **Is better for [agency](https://docs.spacestation14.com/en/space-station-14/core-design.html#player-interactionagency).** Antagonists will have better ways to control how players deal with problems by creating opportunities for spacing. Engineers will have more agency to actually fix problems because the result of their actions (or inaction standing around not fixing anything) will have real consequences for the station. Though mass spacing will need to be discouraged to ensure a better experience.
+
+- **Is easier for players to troubleshoot.** It is much easier to identify and fix a big leak than it is to quietly have air leak away and you can't even tell.
+
+- **Doesn't break distro.** See [Areas are spaced too slowly for vents to ever stop](https://github.com/space-wizards/space-station-14/issues/20293)
+
## New Stuff
This list isn't meant to be exhaustive. Some of the ideas discussed here aren't fully fleshed out. Some of these call for porting mechanics from SS13 with changes as needed/appropriate.
From 04270a121c72ab1547e9c955a23b5f1a06914ae8 Mon Sep 17 00:00:00 2001
From: nikthechampiongr <32041239+nikthechampiongr@users.noreply.github.com>
Date: Fri, 3 May 2024 21:05:24 +0000
Subject: [PATCH 36/80] Add last meeting and reorganize meeting order (#217)
Add minutes for 2024-04-27 admin meeting.
Also re-arranges the order of admin meetings to the same order as
maintainer meetings. For real this time. Last pr I got confused.
---
src/SUMMARY.md | 7 +-
.../admin-meeting-2024-04-27.md | 261 ++++++++++++++++++
2 files changed, 265 insertions(+), 3 deletions(-)
create mode 100644 src/en/admin-meetings/admin-meeting-2024-04-27.md
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 2cc798dc9..c32ee48f7 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -362,7 +362,8 @@ Admin Meetings
==============
----------------------
-- [2024-02-03](en/admin-meetings/admin-meeting-2024-02-03.md)
-- [2024-02-17](en/admin-meetings/admin-meeting-2024-02-17.md)
-- [2024-03-16](en/admin-meetings/admin-meeting-2024-03-16.md)
+- [2024-04-27](en/admin-meetings/admin-meeting-2024-04-27.md)
- [2024-03-30](en/admin-meetings/admin-meeting-2024-03-30.md)
+- [2024-03-16](en/admin-meetings/admin-meeting-2024-03-16.md)
+- [2024-02-17](en/admin-meetings/admin-meeting-2024-02-17.md)
+- [2024-02-03](en/admin-meetings/admin-meeting-2024-02-03.md)
diff --git a/src/en/admin-meetings/admin-meeting-2024-04-27.md b/src/en/admin-meetings/admin-meeting-2024-04-27.md
new file mode 100644
index 000000000..a1cb4fd9b
--- /dev/null
+++ b/src/en/admin-meetings/admin-meeting-2024-04-27.md
@@ -0,0 +1,261 @@
+# Admin Meeting 2024-04-27
+
+## Agenda
+
+
+- Brief updates from last meeting
+- Murderbone
+- Salamander RP
+- Metashield
+- Mandated celebration of the coming of Discourse
+- Discourse
+- Another mandated celebration of the coming of Discourse
+- Review minutes
+
+## Topic Details
+
+
+### Brief updates from last meeting
+
+The last meeting's minutes are available at [link removed]
+
+#### Summary
+
+> - Trialmin event restrictions changed for this batch. I'm not sure how that's gone because I haven't really been involved in this trial batch.
+> - We have gantt charts for trialmins that we're using to keep a schedule for their trials, including deliverables (incredible)
+> - There is a propermin wide trialmin feedback/reporting/thingy thread that has somehow managed to not derail yet I think
+> - I updated the admin application with information on expectations, specifically around time commitment
+> - Murderbone is a topic on this agenda
+> -Chief_Engineer
+
+#### Meeting Goals
+1. Communicate updates related to items from the last meeting to admins attending the meeting.
+
+### Murderbone
+
+#### Summary
+
+
+From the last meeting:
+> Murderboning is currently in a very large gray area and requires clarification. Will be brought up in a future meeting.
+>
+> Basically we need to get at least a rough idea of what is murderbone so that we can put it in the rules when the great rewrite finishes in 7 years. Some important things are that it be clear with minimal gray areas, that it's quick to communicate so that it doesn't add an entire page of rules, and that it be somewhat robust against changes to the games so that we don't have to rewrite it every 2 weeks when something new is added.
+>
+> For some background, murderbone used to be essentially any voluntary and unnecessary round removal of another player. Gibbing people who weren't targets of you for no real reason would have been murderboney. Around a year ago we loosened the definition to basically be mass killing in a way that "isn't interesting". That is omega subjective so literally all I've ever been able to do when people ask is give the example that was given when it was proposed, camping a maint grille is murderbone, running through the halls with an L6 is not.
+>
+> This sort of ties in with mass station sabotage as it seeks to accomplish the same goal, ensure that antags aren't essentially robbing non-antags of gameplay by treating the game like a deathmatch in situations where it is not meant to be a deathmatch. Some important questions are:
+> - How much do we want to enforce this with rules rather than just letting maintainers deal with it?
+> - If we are dealing with it with rules, how much of what we're doing is just compensating for development issues, and should we be compensating that much?
+>
+> I think intrinsically it's going to be easier to communicate this the more extreme we go to either side. Kill anyone if you're an antag and only try to accomplish your objectives are both fairly clear rules, things in the middle generally are not.
+>
+> When we changed this a year ago, I suggested that we do so by just giving all antags a temporary objective to allow them to murderbone, something like "complete your objectives at any cost", "(Optional) die a glorious death" or something, but that's not the option we went with. We're already pretty close to there being no rule, but I generally would still recommend that if loosening rules experimentally, it be done in a way that minimizes the loosening done through the actual text of the rules since it is a lot harder to get everyone on the same page if you need to tighten rules again.
+> -Chief_Engineer
+
+#### Meeting Goals
+
+
+1. Determine the opinions of attending admins about when killing transforms into murderbone.
+2. Determine how to clearly and effectively communicate that to players and other admins.
+
+### Salamander RP
+
+#### Summary
+
+> I have heard from several salamander players that the rp standard on salamander has fallen drastically. They specifically point to metagaming of antags, and EORG as significant issues. We should establish if there is a larger issue and find out how to deal with it. -nikthechampiongr
+
+
+#### Meeting Goals
+
+
+1. Establish whether the rp level on salamander has fallen by a signficant degree and why.
+2. Examine ways to relieve the issue if it exists.
+
+
+### Metashield
+
+#### Summary
+
+
+> Basically we need to get at least a rough idea of what is metagaming so that we can put it in the rules when the great rewrite finishes in 7 years. Some important things are that it be clear with minimal gray areas, that it's quick to communicate so that it doesn't add an entire page of rules, and that it be somewhat robust against changes to the games so that we don't have to rewrite it every 2 weeks when something new is added.
+>
+> imo a decent way to do this is to have a table that lists in one column what is metashielded, in another what causes the metashield to lift, and in another extra info or something like exemptions on who it applies to. Examples can be very effective for communicating rules, but can also take up a lot of space, if there's a way to format things to include collapsed examples for each item, I think we should do that.
+>
+> Also I have this draft https://wiki.spacestation14.io/wiki/User:Chief_Engineer/Metashield
+> -Chief_Engineer
+
+#### Meeting Goals
+
+
+1. Determine the opinions of attending admins about what should be metashielded.
+2. Determine how to clearly and effectively communicate that to players and other admins.
+
+### Mandated celebration of the coming of Discourse
+
+#### Summary
+
+
+> Discourse is here, celebrate. Celebration is required.
+> -Chief_Engineer
+
+#### Meeting Goals
+
+
+1. Ensure that all present have celebrated the coming of Discourse
+
+### Discourse
+
+#### Summary
+
+
+> Discourse is here. Has anyone noticed any issues, or have any concerns right now?
+>
+> What about suggestions?
+>
+> Related thread [Discourse Organization Workshop](https://discord.com/channels/310555209753690112/1233561013945761836)
+> -Chief_Engineer
+
+#### Meeting Goals
+
+
+1. Compile a list of issues that game admin noticed with Discourse
+2. Compile a list of concerns that game admins have with Discourse
+3. Compile a list of actionable suggestions that game admins have for improving Discourse
+
+### Another mandated celebration of the coming of Discourse
+
+#### Summary
+
+
+> Discourse is here, celebrate again. Celebration is still required.
+> -Chief_Engineer
+
+#### Meeting Goals
+
+
+1. Ensure that all present have celebrated the coming of Discourse
+
+### Review minutes
+
+#### Summary
+
+> The meeting minutes provide a record of the meeting for those who could not attend, and they are used to action decisions made in the meeting. For these reasons, it is important that they accurately represent what actually happened in the meeting.
+> -Chief_Engineer
+
+#### Meeting Goals
+
+1. Ensure that nothing important is missing or misrepresented in the minutes.
+2. Attempt to ensure that all topics have met their meeting goals. This can be done by ensuring that each meeting goal is directly addressed by the conclusion of the topic's minutes.
+3. Attempt to ensure that all conclusions fit into one of the following categories:
+ 1. Indicate that a meeting goal was completed.
+ 2. Are something actionable, meaning that they not only call for an action, but that action is specific enough that it does not require answering questions like "what exactly needs to be done?" or "how can this be done?"
+ 3. Clearly indicate that the meeting goals for the topic were not met. Examples: the discussion was tabled, the admin team did not reach a conclusion, the admin team was not able to make the conclusion actionable.
+
+
+```admonish info
+## Attendees
+
+- Chief_Engineer - Headmin
+- Skarlet - Headmin, Mediator
+- Nairod - Headmin
+- metalgearsloth - Project Manager
+- ShadowCommander - Project Manager
+- nikthechampiongr - Propermin, Minutes Editor
+- Crazybrain - Propermin
+- ryan_strudfelt - Propermin
+- Kezu - Propermin
+- Sphiral - Propermin
+- TurboTracker - Propermin
+- WithinElysium - Propermin
+- CptJeanLuc - Propermin
+- ChudGunderson - Propermin
+- Luckyshotpictures - Propermin
+- lunarcomets
+- mirino - Trialmin
+- Aexxie - Trialmin
+```
+
+## Minutes
+
+### Updates from last meeting
+
+
+- Trialmin event restrictions changed. They cannot participate in events. They can host events with supervision near the end of their trial.
+- We got the global trialmin thread and ~~through the power of discourse~~ it has not derailed.
+
+### Defining Murderboning
+
+- Currently murderboning is an extremely large grey area that needs to be properly defined.
+- We could define it as "a traitor going out of their way to murder other players without a reason." This would include killing players which could plausible pose a threat but otherwise are not actively threatening the antagonist, and don't contribute to them completing their objectives.
+- Alternatively we can define the reasons that justify a traitor killing other players:
+ - Killing the player has a strong connection to their objective,
+ - They pose a threat to the traitor at the moment,
+ - or they could plausible be a threat in the future.
+- Additionally we can require that murderboning be a traitor taking a player out of the round permanently rather than simply killing them as medical can often just revive them in a short time. This would allow traitors to be able to murder an incredible amount of people but simply not making them unrevivable.
+- This could simply be moved to admin discretion since it's unbelievably hard to set out a proper definition and most cases can only be resolved on a case-by-case basis.
+- IDEAGUYS: We could just have gameplay consequences, for example having players be automatically be put out as wanted if they reach a certain killcount.
+- This will be put to a thread for further discussion.
+- All of this will be put to a vote in the future.
+
+```admonish info "Conclusion"
+
+#### Conclusion
+
+
+
+Possible changes to the rule will be put up to a vote. The definitions discussed range from just making this fall under admin consensus, or in other ways try to make a set of criterea for what murder boning is that admins can follow. These however cannot reflect all possible situations.
+
+```
+
+### Salamander RP status
+
+- Consensus is that there has been a degredation of RP status on salamander with a lot of cases where players have "LRP+" behavior. E.g. validhunting terminators.
+- We need to brush up on mrp rules and have much stricter enforcement of them.
+- Dewhitelists should be handed out more freely to problematic players.
+ - Dewhitelists can have the following standard: Should a player commit a violation of rp rules, then the handling admin may at their descrition apply dewhitelistment as a punishment.
+- IDEAGUYS: Implement a way for players to properly try to suspect implants, and have a way for them to act on it without having to metagame.
+- We currently do not have a proper definition of MRP. We only have a vague idea.
+ - A proposed definition: Players act according to their role. They are not all knowing and attempt to cooperate with each other in order to accomplish tasks and try to act like this is a real workplace. This is also facilitated through stuff like space law. Even so, players are allowed to deviate from following these standards allowing them to be silly and bending what they are capable of.
+
+```admonish info "Conclusion"
+
+#### Conclusion
+
+There is currently a problem with the rp status on salamander. For now we will start enforcing rp rules strictly. Additionally we will loosen up requirements for dewhitelists to be used as punishments. The mrp status of salamander is very complex, and this will require more work. We will even need to decide what exactly we want "mrp" to be.
+
+```
+
+### Metashield
+
+- We'll be adopting the [Metashield list](https://wiki.spacestation14.io/wiki/User:Chief_Engineer/Metashield) which will be a list containing all the reasonable ways for specific antags, and items to be revealed. This list will be kept up to date routinely as the game gets updated.
+- Ideally this stuff should be dealt with mechanically, however this is monumental task for contributors and maintainers and currently we are nowhere near that point.
+- We'll be sending this to thread hell for further refinement.
+
+### DISCOURSE!!!!
+- DISCOURSE
+- **DISCOURSE**
+- **__DISCOURSE__**!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+
+### Problems with discourse
+
+- Surprisingly nobody has had any issues after having barely used discourse.
+- ~~Clearly this means that discourse is perfect~~
+- This topic will be brought up again in the next meeting.
+- Admins should report issues with discourse on [this thread](https://discord.com/channels/310555209753690112/1233561013945761836)
+
+
+### DISCOURSE THE SECOND
+- LETS GOOO DISCOURSESWjsGDAIJG
+- INVISION IS DEAD REST IN PISS
+
+### Discussion outside Agenda Items
+
+- There is a general problem with RP standards on all servers, not just mrp.
+- We could a deathmatch server to suck away the people that just want to fight.
+
+## Overall Conclusion
+
+Murderboning was discussed. Due to its nature it's extremely hard to define and has been sent for further discussion.
+Salamander's mrp status was discussed and consensus is that it has declined. For now we will be stricter with enforcing mrp rules, and use dewhitelists more often to remove problematic players.
+The metashield list will be adopted.
+Discourse is real. Invision is dead.
From cd7202c512659b1530b474c4930ddbbe427fb9a6 Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Fri, 3 May 2024 23:20:06 +0200
Subject: [PATCH 37/80] Nik had a major skill issue
I got permission from them to make this commit even though i did need it.
---
src/en/admin-meetings/admin-meeting-2024-04-27.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/en/admin-meetings/admin-meeting-2024-04-27.md b/src/en/admin-meetings/admin-meeting-2024-04-27.md
index a1cb4fd9b..cf3df431f 100644
--- a/src/en/admin-meetings/admin-meeting-2024-04-27.md
+++ b/src/en/admin-meetings/admin-meeting-2024-04-27.md
@@ -251,7 +251,7 @@ There is currently a problem with the rp status on salamander. For now we will s
### Discussion outside Agenda Items
- There is a general problem with RP standards on all servers, not just mrp.
-- We could a deathmatch server to suck away the people that just want to fight.
+- We could have a deathmatch server to suck away the people that just want to fight.
## Overall Conclusion
From 15ce9e62e6fa87725397d0d9eea8cdd1968a14d2 Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Fri, 3 May 2024 23:26:17 +0200
Subject: [PATCH 38/80] Fix Design labeler not applying
Webedit ops
---
.github/labeler.yml | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/.github/labeler.yml b/.github/labeler.yml
index 8e7389a90..cc485fc8d 100644
--- a/.github/labeler.yml
+++ b/.github/labeler.yml
@@ -10,5 +10,14 @@
"Scripts":
- 'scripts/**'
+# My goodness gracious.
"Design":
-- 'src/en/proposals/**'
+- 'src/en/general-proposals/**'
+- 'src/en/space-station-14/departments/atmos/proposals/**'
+- 'src/en/space-station-14/departments/cargo-salvage/proposals/**'
+- 'src/en/space-station-14/departments/command/proposals/**'
+- 'src/en/space-station-14/departments/engineering/proposals/**'
+- 'src/en/space-station-14/departments/medical/proposals/**'
+- 'src/en/space-station-14/departments/science/proposals/**'
+- 'src/en/space-station-14/departments/security/proposals/**'
+- 'src/en/space-station-14/departments/service/proposals/**'
From c3872a40420c6d1f59dea5377cc1c4ef675347ec Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Sat, 4 May 2024 00:49:25 +0300
Subject: [PATCH 39/80] Design labeler all match rule (#218)
I think this works?????
---
.github/labeler.yml | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/.github/labeler.yml b/.github/labeler.yml
index cc485fc8d..d0b8f9671 100644
--- a/.github/labeler.yml
+++ b/.github/labeler.yml
@@ -10,14 +10,7 @@
"Scripts":
- 'scripts/**'
-# My goodness gracious.
"Design":
-- 'src/en/general-proposals/**'
-- 'src/en/space-station-14/departments/atmos/proposals/**'
-- 'src/en/space-station-14/departments/cargo-salvage/proposals/**'
-- 'src/en/space-station-14/departments/command/proposals/**'
-- 'src/en/space-station-14/departments/engineering/proposals/**'
-- 'src/en/space-station-14/departments/medical/proposals/**'
-- 'src/en/space-station-14/departments/science/proposals/**'
-- 'src/en/space-station-14/departments/security/proposals/**'
-- 'src/en/space-station-14/departments/service/proposals/**'
+- changed-files:
+ - any-glob-to-any-file: '**/proposals/**'
+ - 'src/en/general-proposals/**'
From 8959ffc68f69058ac586f521687bd72c9a92fca7 Mon Sep 17 00:00:00 2001
From: Vasilis The Pikachu
Date: Sat, 4 May 2024 00:00:16 +0200
Subject: [PATCH 40/80] Minor summery fixes for the player infra section
---
src/SUMMARY.md | 7 ++++---
.../player-interaction/{ => proposals}/grid-inventory.md | 0
2 files changed, 4 insertions(+), 3 deletions(-)
rename src/en/space-station-14/player-interaction/{ => proposals}/grid-inventory.md (100%)
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index c32ee48f7..0077dc85d 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -158,11 +158,12 @@ Space Station 14
- [Player Interaction](en/space-station-14/player-interaction.md)
- [PR Guidelines](en/space-station-14/player-interaction/guidelines.md)
- - [PDA Messaging](en/space-station-14/player-interaction/proposals/pda-messaging.md)
- - [Grid Inventory](en/space-station-14/player-interaction/grid-inventory.md)
+ - [Cartridge loaders](en/space-station-14/player-interaction/cartridge-loaders.md)
- [Proposals]()
- - [PAI Expansion Slots](en/space-station-14/areas/core/player-interaction/proposals/pai-expansion-slots.md)
+ - [PAI Expansion Slots](en/space-station-14/player-interaction/proposals/pai-expansion-slots.md)
+ - [PDA Messaging](en/space-station-14/player-interaction/proposals/pda-messaging.md)
+ - [Grid Inventory](en/space-station-14/player-interaction/proposals/grid-inventory.md)
- [Roleplay/Lore](en/space-station-14/roleplay-lore.md)
- [PR Guidelines](en/space-station-14/roleplay-lore/guidelines.md)
diff --git a/src/en/space-station-14/player-interaction/grid-inventory.md b/src/en/space-station-14/player-interaction/proposals/grid-inventory.md
similarity index 100%
rename from src/en/space-station-14/player-interaction/grid-inventory.md
rename to src/en/space-station-14/player-interaction/proposals/grid-inventory.md
From 6a0fe832d643a7bb8d51d88cb30814fc5ca21c4b Mon Sep 17 00:00:00 2001
From: Vasilis The Pikachu
Date: Sun, 5 May 2024 15:20:19 +0200
Subject: [PATCH 41/80] Fix build error (oops)
---
.../player-interaction/proposals/grid-inventory.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/en/space-station-14/player-interaction/proposals/grid-inventory.md b/src/en/space-station-14/player-interaction/proposals/grid-inventory.md
index 618dbec08..61cc3940b 100644
--- a/src/en/space-station-14/player-interaction/proposals/grid-inventory.md
+++ b/src/en/space-station-14/player-interaction/proposals/grid-inventory.md
@@ -37,7 +37,7 @@ It should never feel sprawling or overwhelming or like you're scanning your scre
Our solution? A to-scale HUD element that can represent uniquely shaped item's as well as display the size of things in an immersive and immediately understandable way.
-![](../../assets/images/grid-inventory/in-game.png)
+![](../../../assets/images/grid-inventory/in-game.png)
### Items
@@ -47,14 +47,14 @@ This is just the shape the item takes up in the grid and it additionally serves
Rather than tiny items having a weight value of 1, they simply take up a single square.
Items would have reasonable default sizes inferred from the current weight values of items with an optional specifier for other custom shapes.
-![](../../assets/images/grid-inventory/shape-examples.png)
+![](../../../assets/images/grid-inventory/shape-examples.png)
Inside of the inventory, you'd be able to manually move around and rotate items, allowing gaps to be filled and space optimized with proper planning.
You'd also be able to intuit how much of the inventory an item fills from a simple glance, since the volume is of the container is represented visually.
### Storage
-![](../../assets/images/grid-inventory/grid-example.png)
+![](../../../assets/images/grid-inventory/grid-example.png)
For the most part, storages exist as literal translations of the current values.
A 28 capacity simply becomes a 7x4 box.
From 5bd56bec33aa68c0a85726ede3ad75c7a486d9a1 Mon Sep 17 00:00:00 2001
From: Jezithyr
Date: Mon, 6 May 2024 14:54:34 -0700
Subject: [PATCH 42/80] Created project manager page with responsibilties
(#220)
---
src/SUMMARY.md | 1 +
src/en/community/projectmanager.md | 38 ++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+)
create mode 100644 src/en/community/projectmanager.md
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 0077dc85d..4b0a73852 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -294,6 +294,7 @@ Community
- [Space Wizards Role Hierarchy](en/community/space-wizards-role-hierarchy.md)
- [Space Wizards Maintainer List](en/community/space-wizards-maintainer-list.md)
- [Discord Rich Presence Repository](en/community/discord-rich-presence-repository.md)
+- [Project Manager](en/community/projectmanager.md)
- [Maintainer](en/community/maintainer.md)
- [Maintainer Policy](en/community/maintainer/wizards-den-maintainer-policy.md)
- [Review Policy](en/community/maintainer/wizards-den-review-policy.md)
diff --git a/src/en/community/projectmanager.md b/src/en/community/projectmanager.md
new file mode 100644
index 000000000..8899146f0
--- /dev/null
+++ b/src/en/community/projectmanager.md
@@ -0,0 +1,38 @@
+# Project Managers
+
+## What are Project Managers (or PMs)?
+
+Project Managers handle a variety of responsibilities when it comes to the SS14 game and community. If there is policy or a high-level decision being made, the project management team will be involved. PM is less of a defined role and more of a higher responsibility with different PMs handling different elements of the game and community. In general if a situation needs escalating then short of involving a Wizard, PMs are where the buck stops so to speak.
+
+The PM team does not appeal bans or get involved in individual player/game disputes unless said dispute is creating an issue of safety or harassment (However some PMs are also game admins and may act in this capacity). The admin team should be your first point of contact for these sorts of issues, with PM's being the nuclear option in an emergency situation where you have fears for your, or another community memeber's safety.
+
+## Areas of Responsibility
+
+All Project Managers have the same level of authority and autonomy when it comes to addressing issues, however some PMs prefer to or are more experienced in handling particular issues. In an emergency any PM will be able to help you, but generally a PM with the appropriate area will be able to address your issue faster and more accurately.
+
+Here is a list of PM's and their responsiblities. Some responsibilities such as Hub Administration and Sensitive Issue handling are not listed publicly to prevent targeted harassment.
+This page may sometimes be out of date, for the most recent responsibilities check discord (If this page is out of date ping @Jezithyr on discord or let a maintainer know).
+
+| Responsibility | Description | Members |
+|---|---|---|
+| Wizards | Highest level of staff in SS14. They are responsibly for handling business-to-business, fincanical, and legal matters. If you think you need to ping a wizard you don't, just talk to a PM instead. | PJB, Zoldorf, Bobda, DrSmugleaf |
+| Project Lead | The GOAT. The supreme nerd overlord. Also someone who is very busy and unless you need help with something very niche and specific, you're better off asking another PM/Maintainer. | PJB |
+| PM Team Lead | The ~~Queen~~ benevolent leader of the PM team. She manages internal disputes and helps the PM team stay on track! | DrSmugleaf |
+| Head Admins | The triumverate in-charge of the admin team. These are the people who *write the rules/policy for the admins* not the people to ask to appeal your ban. | Skarlet, Nairod, Chief_Engineer |
+| Infrastructure | Anything related to the infra running wizden servers andHub/Robust accounts. Outages, connection problems, etc. | Zoldorf, PJB, ShadowCommander, Jezithyr, DrSmugleaf, Chief_Engineer |
+| Project Tech Direction | Technical direction when it comes to code/systems in SS14 and RobustToolbox. Specifically code quality/performance and implementation specifics. | PJB, ElectroSR, ShadowCommander, Jezithyr, DrSmugleaf, Keronshb, Sloth |
+| Project Maintenance | Overseeing the maintainer team and making sure that project guidelines are being properly enforced in PRs, along with helping to manage the number of open PRs | PJB, ElectroSR, ShadowCommander, Jezithyr, DrSmugleaf, Keronshb, Sloth |
+| Engine Development | Works on developing Robust Toolbox | PJB, ElectroSR, ShadowCommander, Jezithyr, DrSmugleaf, Keronshb, Sloth |
+| Content Development | Works on developing Content/Code for SS14 (Specifically WizardsDen servers/upstream) | PJB, ElectroSR, ShadowCommander, Jezithyr, DrSmugleaf, Keronshb, Sloth, Nairod |
+| Documentation | Overseeing the documentation repo and making sure that it is being kept up to date. Primarily focused on the non-ss14 sections of the docs but also holding the maintainer work groups accountable for updating their sections. | ShadowCommander, Jezithyr, DrSmugleaf, Keronshb |
+| Policy | Writes and maintains Wizden/Project-wide policy, such as the hub or general staff policies. | Jezithyr, DrSmugleaf, Sloth, Chief_Engineer, Nairod |
+| Biz Dev | Handles anything related to business-level communication/planning in relation to Space Wizards Federation and SS14. This also includes acting as a point of contact for business entities or journalists. | PJB, Zoldorf, Jezithyr, DrSmugleaf |
+| Game Administration | Handles higher level game administration matters while working with the admin team. May also perform game administration on live severs. | PJB, Emisse, Jezithyr, DrSmugleaf, Skarlet, Chief_Engineer, Nairod |
+| General Administration | Handles general community administration matters such as the forums, discord, or github. | PJB, ShadowCommander, Jezithyr, DrSmugleaf, Skarlet, Chief_Engineer, Nairod, Retequizzle, MushroomLavender |
+| Community Outreach | Handles communication and interaction with the general SS14 community. | Emisse, ElectroSR, ShadowCommander, Jezithyr, Nairod, Retequizzle, MushroomLavender |
+
+
+
+
+
+
From 38b4b82ef994d40115dfd5d7eb059d3af1988c65 Mon Sep 17 00:00:00 2001
From: Jezithyr
Date: Mon, 6 May 2024 15:43:59 -0700
Subject: [PATCH 43/80] Update projectmanager.md
---
src/en/community/projectmanager.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/en/community/projectmanager.md b/src/en/community/projectmanager.md
index 8899146f0..22c50a5f0 100644
--- a/src/en/community/projectmanager.md
+++ b/src/en/community/projectmanager.md
@@ -8,7 +8,7 @@ The PM team does not appeal bans or get involved in individual player/game dispu
## Areas of Responsibility
-All Project Managers have the same level of authority and autonomy when it comes to addressing issues, however some PMs prefer to or are more experienced in handling particular issues. In an emergency any PM will be able to help you, but generally a PM with the appropriate area will be able to address your issue faster and more accurately.
+All Project Managers have the same level of authority and autonomy when it comes to addressing issues, however some PMs prefer to or are more experienced in handling particular issues. In an emergency any PM will be able to help you, but generally a PM with the appropriate area will be able to address your issue faster and more accurately. Although, if you message the wrong PM don't worry we all talk with each other so they'll be able to help you or forward you along to someone who can, it's just faster to start with a PM from that area!
Here is a list of PM's and their responsiblities. Some responsibilities such as Hub Administration and Sensitive Issue handling are not listed publicly to prevent targeted harassment.
This page may sometimes be out of date, for the most recent responsibilities check discord (If this page is out of date ping @Jezithyr on discord or let a maintainer know).
From c5520431af88f24664b9b1273ac10aad2ca99795 Mon Sep 17 00:00:00 2001
From: Jezithyr
Date: Mon, 6 May 2024 15:44:19 -0700
Subject: [PATCH 44/80] Update projectmanager.md
---
src/en/community/projectmanager.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/en/community/projectmanager.md b/src/en/community/projectmanager.md
index 22c50a5f0..3cfaf04d5 100644
--- a/src/en/community/projectmanager.md
+++ b/src/en/community/projectmanager.md
@@ -8,7 +8,7 @@ The PM team does not appeal bans or get involved in individual player/game dispu
## Areas of Responsibility
-All Project Managers have the same level of authority and autonomy when it comes to addressing issues, however some PMs prefer to or are more experienced in handling particular issues. In an emergency any PM will be able to help you, but generally a PM with the appropriate area will be able to address your issue faster and more accurately. Although, if you message the wrong PM don't worry we all talk with each other so they'll be able to help you or forward you along to someone who can, it's just faster to start with a PM from that area!
+All Project Managers have the same level of authority and autonomy when it comes to addressing issues, however some PMs prefer to or are more experienced in handling particular issues. In an emergency any PM will be able to help you, but generally a PM with the appropriate area will be able to address your issue faster and more accurately. *Although, if you message the wrong PM don't worry we all talk with each other so they'll be able to help you or forward you along to someone who can, it's just faster to start with a PM from that area!*
Here is a list of PM's and their responsiblities. Some responsibilities such as Hub Administration and Sensitive Issue handling are not listed publicly to prevent targeted harassment.
This page may sometimes be out of date, for the most recent responsibilities check discord (If this page is out of date ping @Jezithyr on discord or let a maintainer know).
From 5ed34eb03abeb4bd0ccbb9362be5e6062ad162fe Mon Sep 17 00:00:00 2001
From: Chief-Engineer <119664036+Chief-Engineer@users.noreply.github.com>
Date: Wed, 22 May 2024 16:29:47 -0500
Subject: [PATCH 45/80] Update Wizard's Den Admin Policy (#223)
---
src/en/community/admin/wizards-den-admin-policy.md | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/en/community/admin/wizards-den-admin-policy.md b/src/en/community/admin/wizards-den-admin-policy.md
index e702c1b0f..360f0f890 100644
--- a/src/en/community/admin/wizards-den-admin-policy.md
+++ b/src/en/community/admin/wizards-den-admin-policy.md
@@ -12,7 +12,9 @@ Administrators are **not unaccountable**, and should be held to higher standards
Professionalism is important, and in general will help reduce the number of issues you run into as staff. We expect you to **deescalate**, rather than escalate situations.
As staff, you're often the first person that a player with an issue will talk to. No matter your opinion on the player, do your best to be respectful towards them.
#### 1.3 **Do not leak or share sensitive information without permission.**
-This *does* pertain to any information posted in the game admin Discord chats, information discussed in admin chat in-game, as well as PII (IP, HWID) accessible through the central ban DB. This does *not* pertain to basic ban info (time, reason, count), admin notes, or admin log information.
+This *does* pertain to any information posted in the game admin Discord chats, forum categories, information discussed in admin chat in-game, as well as PII (IP, HWID) accessible through the central ban DB. This does *not* pertain to basic ban info (time, reason, count), admin notes, or admin log information.
+
+This policy also covers and prohibits internal leaks. An example of an internal leak would be an Admin A sharing information about Admin B's application vote/discussion with Admin B, if Admin B doesn't have direct access to all the information that was being shared by Admin A. Generally, "leak" means to share the information in whole or in part with someone who does not have direct access.
#### 1.4 **Ban Appeals**
Ban appeals are covered by the [Banning Policy](./wizards-den-banning-policy.md).
From d42b236757e88fde8dd92ca0bda9c0e03da7afd1 Mon Sep 17 00:00:00 2001
From: Pieter-Jan Briers
Date: Thu, 23 May 2024 21:13:42 +0200
Subject: [PATCH 46/80] Update old URLs to central.spacestation14.io
---
src/en/community/admin/admin-tooling.md | 2 +-
src/en/server-hosting/oauth.md | 8 ++++----
src/en/server-hosting/setting-up-ss14-admin.md | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/en/community/admin/admin-tooling.md b/src/en/community/admin/admin-tooling.md
index 53ad3817f..99821ad6a 100644
--- a/src/en/community/admin/admin-tooling.md
+++ b/src/en/community/admin/admin-tooling.md
@@ -184,7 +184,7 @@ Use the `list` command to list all available commands, and the `help 'OpenIDConnect',
'data' => [
- 'providerURL' => 'https://central.spacestation14.io/web/',
+ 'providerURL' => 'https://account.spacestation14.com/',
'clientID' => 'e584f64f-d0f9-4b15-9714-1233bc4c55a4', // Replace with your client ID.
'clientsecret' => 'foobar', // Replace with your client secret.
'scope' => [ 'profile', 'email' ]
diff --git a/src/en/server-hosting/setting-up-ss14-admin.md b/src/en/server-hosting/setting-up-ss14-admin.md
index a165e09fa..6e6cfd423 100644
--- a/src/en/server-hosting/setting-up-ss14-admin.md
+++ b/src/en/server-hosting/setting-up-ss14-admin.md
@@ -67,11 +67,11 @@ ForwardProxies:
# Your way of authenticating accounts, the docs will set it up with an ss14 account
Auth:
- Authority: "https://central.spacestation14.io/web/"
+ Authority: "https://account.spacestation14.com/"
ClientId: "9e2ce26f-EDIT-THIS-b4d9-8cc08993b33e"
ClientSecret: "foobar"
-authServer: "https://central.spacestation14.io/auth"
+authServer: "https://auth.spacestation14.com"
```
```admonish warning
@@ -81,7 +81,7 @@ I will STRONGLY recommend you put this behind a reverse proxy if you are not alr
## Authentication config
This is a pretty important one, it will be your way of authenticating with the webpanel. Anyone with administrator permissions on your server automaticly gets access to the webpanel. We will use Space Station 14 Accounts for this.
-1. Log in into and go to https://central.spacestation14.io/web/Identity/Account/Manage/Developer and click on "New OAuth App"
+1. Log in into and go to https://account.spacestation14.com/Identity/Account/Manage/Developer and click on "New OAuth App"
2. Type in an app name, this can be anything
3. For an Callback url should be `PathBase/signin-oidc`. Should look like this `https://YOURDOMAIN.TLD/admin/signin-oidc`
4. Homepage url should be wherever your pathbase is. Like `https://YOURDOMAIN.TLD/admin/`
From 5bcb4e16d47dae0939a7a3cf4bd1df9c1ca1ac48 Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Sun, 26 May 2024 17:51:49 +0200
Subject: [PATCH 47/80] Update server-hosting-tutorial.md
---
src/en/general-development/setup/server-hosting-tutorial.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/en/general-development/setup/server-hosting-tutorial.md b/src/en/general-development/setup/server-hosting-tutorial.md
index 637c4e8a8..ccbc90d54 100644
--- a/src/en/general-development/setup/server-hosting-tutorial.md
+++ b/src/en/general-development/setup/server-hosting-tutorial.md
@@ -7,7 +7,7 @@ Hosting a local sandbox server for playing around is easy, but setting up a larg
1. Download and install the [.NET 8 Runtime](https://dotnet.microsoft.com/download). You only need "x64" under "run console apps" not "hosting bundle" from the downloads page.
2. Download the latest version of the server from [our builds page](https://central.spacestation14.io/builds/wizards/builds.html), for your operating system. If you are running custom code, or a build is not available for your platform, see [Custom Code](#custom-code) below.
3. Extract that to a directory somewhere.
-4. Run `Robust.Server.exe` (or `Robust.Server` [via terminal on macOS/Linux](#running-the-server-on-macos-or-linux))
+4. Run `run_server.bat` (Windows) or (or `Robust.Server` [via terminal on macOS/Linux](#running-the-server-on-macos-or-linux))
5. Open your Space Station 14 Launcher and click on ``Direct Connect To Server`` and type in ``localhost`` and click connect. You can also add it as a favorite if you click the ``Add Favorite`` button.
6. When there is a new update. Go back to the second step and just overwrite the files to update your server.
From 85c143ccd2b2c74b65664a0d2403f56f5c3b2495 Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Sun, 26 May 2024 19:59:27 +0200
Subject: [PATCH 48/80] Fix wording for hosting lvl 0
Doing commits with 1% battery was not a good idea.
---
src/en/general-development/setup/server-hosting-tutorial.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/en/general-development/setup/server-hosting-tutorial.md b/src/en/general-development/setup/server-hosting-tutorial.md
index ccbc90d54..06f208bac 100644
--- a/src/en/general-development/setup/server-hosting-tutorial.md
+++ b/src/en/general-development/setup/server-hosting-tutorial.md
@@ -7,7 +7,7 @@ Hosting a local sandbox server for playing around is easy, but setting up a larg
1. Download and install the [.NET 8 Runtime](https://dotnet.microsoft.com/download). You only need "x64" under "run console apps" not "hosting bundle" from the downloads page.
2. Download the latest version of the server from [our builds page](https://central.spacestation14.io/builds/wizards/builds.html), for your operating system. If you are running custom code, or a build is not available for your platform, see [Custom Code](#custom-code) below.
3. Extract that to a directory somewhere.
-4. Run `run_server.bat` (Windows) or (or `Robust.Server` [via terminal on macOS/Linux](#running-the-server-on-macos-or-linux))
+4. Run `run_server.bat` (Windows) or `Robust.Server` [via terminal on macOS/Linux](#running-the-server-on-macos-or-linux))
5. Open your Space Station 14 Launcher and click on ``Direct Connect To Server`` and type in ``localhost`` and click connect. You can also add it as a favorite if you click the ``Add Favorite`` button.
6. When there is a new update. Go back to the second step and just overwrite the files to update your server.
From 99b364bd7540c3bcf78b53ac1e918d5362fd8bde Mon Sep 17 00:00:00 2001
From: Pieter-Jan Briers
Date: Mon, 27 May 2024 15:23:59 +0200
Subject: [PATCH 49/80] Add translation doc
---
src/SUMMARY.md | 1 +
.../contributing-translations.md | 16 ++++++++++++++++
2 files changed, 17 insertions(+)
create mode 100644 src/en/general-development/contributing-translations.md
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 4b0a73852..d388f0539 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -38,6 +38,7 @@ General Development
- [Feature Proposal Template](en/templates/proposal.md)
- [Expected Team Decorum & Usage](en/general-development/feature-proposals/expected-feature-proposal-decorum.md)
- [Work Groups](en/general-development/work-groups.md)
+- [Contributing Translations](en/general-development/contributing-translations.md)
SS14 By Example
===============
diff --git a/src/en/general-development/contributing-translations.md b/src/en/general-development/contributing-translations.md
new file mode 100644
index 000000000..a4894c928
--- /dev/null
+++ b/src/en/general-development/contributing-translations.md
@@ -0,0 +1,16 @@
+# Contributing Translations
+
+```admonish info
+The main game **cannot** be translated for now. While the game itself does support localization as well, we currently do not want to accept upstream translations as they cannot actually be used by players on official servers.
+```
+
+Translating the game to other languages is relatively easy! No programming knowledge or special software is required, just an understanding of English and whatever language you're translating to.
+
+## Getting Started
+
+Translation of the game is handled via [Weblate](https://weblate.spacestation14.com/). This program provides an easy interface for translators to submit translations. To get started, you can simply sign in with your existing Space Station 14 account.
+
+As a new user, you only have the ability to submit suggestions. These need to be reviewed by another translator before being accepted. If you want to get full translator permissions (ability to direct save translations yourself), **just ask** in Discord or on the Forum, there's no high barrier of entry here. Same thing if you submit suggestions and they don't get approved by an existing translator a week later.
+
+If the language you want to translate to doesn't exist yet, also **just ask**. It requires a bit of manual work to set everything up for a new language.
+
From 94ab64b593750cfa979c18d1dce1178378a94770 Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Tue, 28 May 2024 14:04:08 +0200
Subject: [PATCH 50/80] Add cd instruction to git bash instructions
Prevents some confusion with people trying to run git commands in the same directory they were in after cloning.
---
.../setup/git-for-the-ss14-developer.md | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/en/general-development/setup/git-for-the-ss14-developer.md b/src/en/general-development/setup/git-for-the-ss14-developer.md
index bfd4d72e0..49e47db07 100644
--- a/src/en/general-development/setup/git-for-the-ss14-developer.md
+++ b/src/en/general-development/setup/git-for-the-ss14-developer.md
@@ -128,6 +128,11 @@ Then, we'll enter the command for cloning **our** remote repository--not the `sp
![](https://i.imgur.com/Xn4AQLf.png)
+Then **c**hange **d**irectory using:
+``cd space-station-14``
+
+(This may be diffrent if you cloned another fork, it's almost always being the same as the repository name)
+
Every Git command will look something like this--`git` and then a keyword like `add`, `commit`, `pull`, etc.
@@ -773,4 +778,4 @@ git fetch [username]
git checkout [username]/[branch name]
```
-This also lets you make PRs to their remote branch, if you so desired.
\ No newline at end of file
+This also lets you make PRs to their remote branch, if you so desired.
From f96793a2abf095fd77fe1bf3496a2b75bccaa996 Mon Sep 17 00:00:00 2001
From: Vasilis The Pikachu
Date: Thu, 30 May 2024 16:42:35 +0200
Subject: [PATCH 51/80] Fix design doc header not rendering properly in some
files
---
.../space-station-14/departments/atmos/proposals/atmos-rework.md | 1 +
.../departments/engineering/proposals/engine-containment.md | 1 +
.../engineering/proposals/machine-upgrading-rework.md | 1 -
.../departments/engineering/proposals/power-generation.md | 1 +
.../departments/engineering/proposals/signaller-rework.md | 1 +
.../departments/science/proposals/xenoarch-redux.md | 1 +
.../departments/security/proposals/genpop-prisoners.md | 1 +
.../departments/service/proposals/plant-genetics.md | 1 +
.../round-flow/proposals/cleanup-crew-gamemode.md | 1 +
src/en/space-station-14/round-flow/proposals/game-director.md | 1 +
.../round-flow/proposals/pizza-delivery-critter.md | 1 +
src/en/space-station-14/round-flow/proposals/rogue-drones.md | 1 +
src/en/space-station-14/round-flow/proposals/turf-war.md | 1 +
src/en/space-station-14/user-interface/proposals/statpanels.md | 1 +
14 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/en/space-station-14/departments/atmos/proposals/atmos-rework.md b/src/en/space-station-14/departments/atmos/proposals/atmos-rework.md
index 149f78315..374bfb569 100644
--- a/src/en/space-station-14/departments/atmos/proposals/atmos-rework.md
+++ b/src/en/space-station-14/departments/atmos/proposals/atmos-rework.md
@@ -3,6 +3,7 @@
This document is ported from before the game-area reorganization and has not been reviewed or updated.
It may not fit with the new design requirements.
```
+
| Designers | Implemented | GitHub Links |
|---|---|---|
| notafet | :warning: Partially | https://github.com/space-wizards/space-station-14/pull/21954 https://github.com/space-wizards/space-station-14/pull/22358 https://github.com/space-wizards/space-station-14/pull/22468 |
diff --git a/src/en/space-station-14/departments/engineering/proposals/engine-containment.md b/src/en/space-station-14/departments/engineering/proposals/engine-containment.md
index 64009e07b..548178504 100644
--- a/src/en/space-station-14/departments/engineering/proposals/engine-containment.md
+++ b/src/en/space-station-14/departments/engineering/proposals/engine-containment.md
@@ -3,6 +3,7 @@
This document is ported from before the game-area reorganization and has not been reviewed or updated.
It may not fit with the new design requirements.
```
+
| Designers | Implemented | GitHub Links |
|---|---|---|
| Flareguy, CptJeanLuc |:x: No | TBD |
diff --git a/src/en/space-station-14/departments/engineering/proposals/machine-upgrading-rework.md b/src/en/space-station-14/departments/engineering/proposals/machine-upgrading-rework.md
index 99f77df45..3f36544bd 100644
--- a/src/en/space-station-14/departments/engineering/proposals/machine-upgrading-rework.md
+++ b/src/en/space-station-14/departments/engineering/proposals/machine-upgrading-rework.md
@@ -1,5 +1,4 @@
# Machine Upgrading Rework
-
```admonish warning "Attention: Legacy Documentation!"
This document is ported from before the game-area reorganization and has not been reviewed or updated.
It may not fit with the new department design requirements.
diff --git a/src/en/space-station-14/departments/engineering/proposals/power-generation.md b/src/en/space-station-14/departments/engineering/proposals/power-generation.md
index 5a67f328b..96b74b9d8 100644
--- a/src/en/space-station-14/departments/engineering/proposals/power-generation.md
+++ b/src/en/space-station-14/departments/engineering/proposals/power-generation.md
@@ -3,6 +3,7 @@
This document is ported from before the game-area reorganization and has not been reviewed or updated.
It may not fit with the new design requirements.
```
+
| Designers | Implemented | GitHub Links |
|---|---|---|
| tday93 | :x: No | TBD |
diff --git a/src/en/space-station-14/departments/engineering/proposals/signaller-rework.md b/src/en/space-station-14/departments/engineering/proposals/signaller-rework.md
index 3047d82cc..5712ddabb 100644
--- a/src/en/space-station-14/departments/engineering/proposals/signaller-rework.md
+++ b/src/en/space-station-14/departments/engineering/proposals/signaller-rework.md
@@ -3,6 +3,7 @@
This document is ported from before the game-area reorganization and has not been reviewed or updated.
It may not fit with the new design requirements.
```
+
| Designers | Implemented | GitHub Links |
|---|---|---|
| deltanedas | :x: No | TBD |
diff --git a/src/en/space-station-14/departments/science/proposals/xenoarch-redux.md b/src/en/space-station-14/departments/science/proposals/xenoarch-redux.md
index ee6b99796..6837ab3b7 100644
--- a/src/en/space-station-14/departments/science/proposals/xenoarch-redux.md
+++ b/src/en/space-station-14/departments/science/proposals/xenoarch-redux.md
@@ -3,6 +3,7 @@
This document is ported from before the game-area reorganization and has not been reviewed or updated.
It may not fit with the new design requirements.
```
+
| Designers | Implemented | GitHub Links |
|-----------------|---|---|
| Thee EmoGarbage | :x: No | TBD |
diff --git a/src/en/space-station-14/departments/security/proposals/genpop-prisoners.md b/src/en/space-station-14/departments/security/proposals/genpop-prisoners.md
index a70e69db8..ebc9406b2 100644
--- a/src/en/space-station-14/departments/security/proposals/genpop-prisoners.md
+++ b/src/en/space-station-14/departments/security/proposals/genpop-prisoners.md
@@ -3,6 +3,7 @@
This document is ported from before the game-area reorganization and has not been reviewed or updated.
It may not fit with the new design requirements.
```
+
| Designers | Implemented | GitHub Links |
|---|---|---|
| ike709 | :x: No | TBD |
diff --git a/src/en/space-station-14/departments/service/proposals/plant-genetics.md b/src/en/space-station-14/departments/service/proposals/plant-genetics.md
index 9f8074bb8..906510118 100644
--- a/src/en/space-station-14/departments/service/proposals/plant-genetics.md
+++ b/src/en/space-station-14/departments/service/proposals/plant-genetics.md
@@ -3,6 +3,7 @@
This document is ported from before the game-area reorganization and has not been reviewed or updated.
It may not fit with the new design requirements.
```
+
| Designers | Implemented | GitHub Links |
|---|---|---|
| deltanedas | :x: No | TBD |
diff --git a/src/en/space-station-14/round-flow/proposals/cleanup-crew-gamemode.md b/src/en/space-station-14/round-flow/proposals/cleanup-crew-gamemode.md
index 45865af25..9585b91ce 100644
--- a/src/en/space-station-14/round-flow/proposals/cleanup-crew-gamemode.md
+++ b/src/en/space-station-14/round-flow/proposals/cleanup-crew-gamemode.md
@@ -3,6 +3,7 @@
This document is ported from before the game-area reorganization and has not been reviewed or updated.
It may not fit with the new design requirements.
```
+
| Designers | Implemented | GitHub Links |
|---|---|---|
| mirrorcult | :x: No | TBD |
diff --git a/src/en/space-station-14/round-flow/proposals/game-director.md b/src/en/space-station-14/round-flow/proposals/game-director.md
index 589a5ad23..d23cef5ba 100644
--- a/src/en/space-station-14/round-flow/proposals/game-director.md
+++ b/src/en/space-station-14/round-flow/proposals/game-director.md
@@ -3,6 +3,7 @@
This document is ported from before the game-area reorganization and has not been reviewed or updated.
It may not fit with the new design requirements.
```
+
| Designers | Implemented | GitHub Links |
|---|---|---|
| tom-leys (RecallSingularity) | :information_source: Open PR | https://github.com/space-wizards/space-station-14/pull/16548 |
diff --git a/src/en/space-station-14/round-flow/proposals/pizza-delivery-critter.md b/src/en/space-station-14/round-flow/proposals/pizza-delivery-critter.md
index 63bf1edc2..599d3aca9 100644
--- a/src/en/space-station-14/round-flow/proposals/pizza-delivery-critter.md
+++ b/src/en/space-station-14/round-flow/proposals/pizza-delivery-critter.md
@@ -3,6 +3,7 @@
This document is ported from before the game-area reorganization and has not been reviewed or updated.
It may not fit with the new design requirements.
```
+
| Designers | Implemented | GitHub Links |
| -------------- | ----------- | ------------ |
| FairlySadPanda | :x: No | TBD |
diff --git a/src/en/space-station-14/round-flow/proposals/rogue-drones.md b/src/en/space-station-14/round-flow/proposals/rogue-drones.md
index 8deb4ab08..c6c356a70 100644
--- a/src/en/space-station-14/round-flow/proposals/rogue-drones.md
+++ b/src/en/space-station-14/round-flow/proposals/rogue-drones.md
@@ -3,6 +3,7 @@
This document is ported from before the game-area reorganization and has not been reviewed or updated.
It may not fit with the new design requirements.
```
+
| Designers | Implemented | GitHub Links |
|---|---|---|
| mirrorcult | :x: No | TBD |
diff --git a/src/en/space-station-14/round-flow/proposals/turf-war.md b/src/en/space-station-14/round-flow/proposals/turf-war.md
index 9ffc382dd..363a104a2 100644
--- a/src/en/space-station-14/round-flow/proposals/turf-war.md
+++ b/src/en/space-station-14/round-flow/proposals/turf-war.md
@@ -3,6 +3,7 @@
This document is ported from before the game-area reorganization and has not been reviewed or updated.
It may not fit with the new design requirements.
```
+
| Designers | Implemented | GitHub Links |
|---|---|---|
| deltanedas | :warning: partially | [#23290](https://github.com/space-wizards/space-station-14/pull/23290) |
diff --git a/src/en/space-station-14/user-interface/proposals/statpanels.md b/src/en/space-station-14/user-interface/proposals/statpanels.md
index 022f4a033..00fca665a 100644
--- a/src/en/space-station-14/user-interface/proposals/statpanels.md
+++ b/src/en/space-station-14/user-interface/proposals/statpanels.md
@@ -3,6 +3,7 @@
This document is ported from before the game-area reorganization and has not been reviewed or updated.
It may not fit with the new design requirements.
```
+
| Designers | Implemented | GitHub Links |
|---|---|---|
| ike709 | :x: No | WYCI |
From c7dae6532780968353cbd2af5d9ce0b3cc707685 Mon Sep 17 00:00:00 2001
From: SlamBamActionman <83650252+SlamBamActionman@users.noreply.github.com>
Date: Fri, 31 May 2024 08:10:06 +0200
Subject: [PATCH 52/80] Reduced Metagaming Mechanics (#214)
This proposal aims to reduce the impact metaknowledge has on the game by
shifting it from being a rules-enforced system to a mechanics-enforced
system. This will reduce ambiguity for what constitutes a rulebreak,
reduce admin workload and better align player knowledge with character
knowledge.
The proposal identifies 5 "problems" currently in the game where
knowledge about the game is restricted via rules enforcement, and
suggests changes that allow players to possess and act upon the
knowledge while making it harder to do so without proper justification.
The important part of the proposal is the identification of issues and
attempts to solve them; the particulars of a specific solution (e.g. the
damage proposed in the "Implant Problem") is malleable based on
feedback.
---------
Co-authored-by: Kara
---
src/SUMMARY.md | 1 +
.../security/proposals/reduced-metagaming.md | 260 ++++++++++++++++++
2 files changed, 261 insertions(+)
create mode 100644 src/en/space-station-14/departments/security/proposals/reduced-metagaming.md
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index d388f0539..599757f8f 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -235,6 +235,7 @@ Space Station 14
- [Proposals]()
- [GenPop Prisoners](en/space-station-14/departments/security/proposals/genpop-prisoners.md)
+ - [Reduced Metagaming Mechanics](en/space-station-14/departments/security/proposals/reduced-metagaming.md)
- [Service](en/space-station-14/departments/service.md)
- [PR Guidelines](en/space-station-14/departments/service/guidelines.md)
diff --git a/src/en/space-station-14/departments/security/proposals/reduced-metagaming.md b/src/en/space-station-14/departments/security/proposals/reduced-metagaming.md
new file mode 100644
index 000000000..946585978
--- /dev/null
+++ b/src/en/space-station-14/departments/security/proposals/reduced-metagaming.md
@@ -0,0 +1,260 @@
+# Reducing Metagaming
+
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| SlamBamActionman | :x: No | TBD |
+
+## Overview
+
+This proposal contains a list of design changes and features aiming to reduce the impact of metaknowledge in the game. While the proposal touches on several different issues the changes proposed affect each other and overlap, which is why they're all compiled here. The overarching theme is moving away from rule enforcement to mechanical enforcement, allowing crew players to possess general knowledge about antags but make it harder to apply it in a round without proper reasoning.
+
+## Background
+
+Right now there are several instances in the game where admins are expected to enforce rules related to metagaming. Some of these are related to the current round (e.g. using knowledge gained as a ghost after being revived), but there are also rules disallowing knowledge about the game in general. This mostly includes knowledge about antagonist items, behaviors and round events. This kind of "*metaknowledge*" rules are primarily restricted to Security and Command, and there are examples of metaknowledge that is allowed under the rules; knowing where maints loot spawns, secret Chemistry recipes and recognizing modifications to station layouts.
+
+There are two ways to reduce the impact of metaknowledge: allow it in the rules, or make it unviable to act upon it. Often this is done in combination; uplinks are an example of this. It's pretty much impossible to find out if a locked PDA is an uplink due to the high number of permutations in the lock. While it's technically possible for Security to confiscate every roundstart PDA and replace them with ones from the P-Tech vendor, it's simply not feasible in practice. This becomes more of an issue when a specific person has been suspected of being Syndicate (which is why we have stringent rules about PDA confiscating still) but it shows there are ways to design around metaknowledge.
+
+The negative impact enforcement of metaknowledge is the following:
+- Players need to self-assess what counts as abusing metaknowledge, possibly over-correcting as there's no ingame feedback.
+- Disagreements about whether someone is abusing metaknowledge (e.g. a SecOff testing a pair of gloves for chameleon) can easily occur between players in a round, and is highly contextual.
+- Admins need to put in time and resources enforcing these rules, which is always desirable to reduce.
+- Players have to pretend they don't know about certain mechanics.
+
+To find out where these problems lie, [I created a thread on the Discord](https://discord.com/channels/310555209753690112/1227226189358174209) to gather feedback from the playerbase where they have percieved metaknowledge abuse. This feedback is used as a basis for the changes and will be cited throughout the proposal.
+
+The proposal will contain both mechanical design changes as well as rule changes. The rule changes are necessary as the goal of the PR is to reduce admin workload, and where it's not possible to eliminate them the goal will be to make them more clear and reduce grayzones.
+
+### Security & Resources
+
+Other than explicit rules and Space Law, the main thing holding Security back is **time**, **materials**, **personnel** and **information**. Performing a search takes time, which holds up a SecOff that then becomes unable to respond or assist in other duties. Needing to utilize guns, stun batons and flashes means a SecOff must return to Sec to refill, and if materials are scarce this wait can be even longer. Similarly, health is a resource which will cause time and personnel loss from the SecOff needing to be treated.
+
+Information helps mitigate these losses; knowing who to search, what materials to prepare and where to go. The more Security has of each resource the more effective it will be, and overabundance of one resource can make up for the lack of another. Some of these resources put strain on other departments however; materials may be necessary to craft or refill vital Security equipment, but those materials come from Cargo's work. Any rule change that relaxes the requirements on Security should instead impose a drain on its resources. For example, guessing uplink codes is usually too much of a timesink and takes up an officer's attention despite it being allowed by the rules, so it's rarely done.
+
+## The Implant Problem
+
+```admonish quote
+Implant checking someone "just in case" after being arrested for some unrelated crime.
+```
+
+Implants are very useful to Syndicates since they allow direct access to certain functionality and are hidden by default. Security is unable to detect an implant unless it has been used, though it may be suspected through circumstantial evidence. The DNA Scrambler is a great example of this; if it's not witnessed being used, Security will first have to a) find the user, b) detect they are not on the manifest, c) make a determination whether a DNA implanter was used and/or find the used implanter.
+
+There is a big weakness to implants however. SecOffs can use an implanter to extract implants, and the mechanical limitation to this is relatively minor. Acquiring an implanter can be easily done via Medical, and while the doafter to use one is pretty long it's nothing compared to the brig times a suspected antag may have. This means they can be very easily taken away from the antag by any SecOff who wishes to do the procedure.
+
+Strangely, implant searches are much more restrictive on MRP. To check, Security must have witnessed an implant being used, or any other explanation must be *extremely* unlikely. This requirement is held up to an almost absurd amount; you can't check for a Storage or Uplink implant if someone suddenly has a weapon in perma, because someone could have broken in, given them the gun and then left after repairing the hole. This means subtle implants or one-time use implants like the Storage Implant and DNA Scrambler are much more valuable on MRP since a suspicion is nowhere near enough to be allowed to implant check.
+
+### Proposed Solution
+
+Security should not have any rule limitations on checking implants, but instead Security should be mechanically discouraged from performing random implant checks. I propose the following:
+- Rule change: Security has knowledge of implants; that they exist, and what types the Syndicate have access to.
+- Rule change: Security has no limitations on performing implant checks.
+- Checks can only be performed with the new **Implant Extractor**, a device that can be printed in the Medfab.
+- To extract, the Implant Extractor must be set to the specific type of implant to be extracted. A doafter is then performed.
+ - If successful, the chosen implant gets extracted into the Implant Extractor similar to how an Implanter is done now.
+ - If unsuccessful, no implant is extracted. The user that tried to use the Implant Extractor takes 45 Cellular damage, ignoring resistances, as the device backfires.
+
+The main point is the damage taken by the Implant Extractor. Performing an implant check without sufficient suspicion and being wrong becomes a very high price to pay, encouraging Security to be sure of their search. Even a single failed search essentially requires the user to be sent to the medbay, and two puts them out of commission for a long time.
+
+Note: The particulars of this suggestion may change as Newmed/Surgery gets implemented. The important part is that implant searching someone without being correct should punish Security by temporarily taking away a resource, in this case in the form of personnel. The exact nature of the damage and restriction on resources could change.
+
+## The PDA / Uplink Problem
+
+```admonish quote
+Confiscating PDAs of anyone you suspect of being a traitor without proof.
+```
+
+Uplinks are in a kind of weird situation where it's one of the most powerful tools for a Traitor and in-universe a very well-hidden feature, but at the same time it's also one of the easiest metaknowledge items in the game. As soon as a player has been found using a traitor-exclusive item Security players have to pretend that the PDA isn't a high target to confiscate. The reason for this is because you generally want antags to be able to use all their TC during a round to make it interesting. As such, the PDA may only be confiscated for two reasons:
+- Security finds an open uplink in the PDA.
+- Security has previously found an open uplink in another PDA, and can thus pre-emptively confiscate any PDA they have reasonable suspicion of having an uplink.
+
+Right now the rules are the main way of preventing overzealous Security confiscating PDAs. Traitors do have a gameplay option as well: The Uplink Implant. This implant does have the benefit of making PDA confiscating a non-issue, but the tradeoff is 2 less TC and an implanter that must be disposed of, and with the stringent rules on PDA confiscating it's unlikely to get any benefit from it. There's no reason to keep the uplink open after the implant is used, so you only get value if another uplink has been found. Additionally it suffers from the vulnerability of implant checks.
+
+### Proposed Solution
+
+The PDA is very easily the single point of failure with this problem, but it's also unique in its ringtone lock. Confiscating a PDA does come with some cost to Security in that they need to secure a replacement; worth it for a confirmed Syndie, but not viable for all arrests. If we were to remove the limitations on Security randomly confiscating PDAs there would need to be an equally effective method of eluding detection. It would also need to incur a cost for Security to confiscate. I propose the following:
+
+- Rule change: Security has knowledge PDAs can contain Uplinks, and may confiscate them if they have a reason to believe it could contain one.
+- Uplink Implanter cost is reduced to 1 TC, and changes proposed in "The Implant Problem" are also included.
+- The Uplink Patch is a new device that can be bought from the Uplink for 1 TC.
+ - The Uplink Patch can be attached to any object and turns it into an Uplink.
+ - The Uplink can be locked and unlocked by saying one of the agent codewords while wearing/holding/carrying the object.
+ - TC must be inserted into the object to purchase anything.
+
+The Uplink Patch would turn any object into a possible Uplink, making the permutations for what to confiscate anything in the Syndie's inventory. Even if a SecOff would be overzealous and try to take everything, the uplink could be an implant as well. With the changes in the Implant Problem, this would require Security to have strong suspicion of where the uplink would be to actually catch it.
+
+## The Thief Gloves Problem
+
+```admonish quote
+Checking black gloves without proper evidence leading to them
+```
+```admonish quote
+Checking for Chameleon gear when there is no reason to suspect it feels kinda metagaming, yeah? Especially since you now have to put the items on to even check.
+```
+
+Thief gloves come in two varieties, each with their own problem.
+
+1. Normal Thief Gloves are indistuingishable from black gloves. The only way to know they have been used is if someone finds out an item on their person has been stolen, and even then Security are not allowed to know they must search for black gloves unless an uplink has been previously found. They also stand out for crew who don't normally wear black gloves, making overzealous SecOffs search and possibly even confiscate them.
+
+2. Chameleon Thief Gloves mean to remedy this. However, as they leave holographic fibers on everything they touch it becomes very obvious whenever they have been used. It leads to a rather opaque and unintuitive game of trying to not wear the thief gloves except in the most critical of moments, making finding a spare pair of gloves in someone's bag highly suspicious. They're also trivial to check since it's just to put them on and check whether they allow Chameleon properties.
+
+### Proposed Solution
+
+- Thieving Gloves and Chameleon Thieving Gloves are merged into a single item: The Thief Glovebox.
+ - When purchased/obtained, the user is given a box. Opening this box activates a UI similar to a Chameleon UI.
+ - Once a glove design is chosen, the user is given a pair of thieving gloves with that design.
+ - The gloves give off matching fibers. They are not Chameleon.
+- Non-engineering insulated gloves/budget insulated gloves now come in 3 different colors with corresponding colored fibers. They are still called "Insulated Gloves"/"Budget Insulated Gloves".
+- Rule change: Security has knowledge of Thieving Gloves and may confiscate the gloves of anyone who has stolen or attempted to steal contraband.
+- Rule change: An additional rule is added: Security may *not* test Thieving Gloves by putting them on and trying to steal an item off someone, as this would count as Security using antag items. *Note that this rule would not be necessary if the changes proposed in The Disguised Items Problem are implemented.*
+
+This means that a thief is safe from having their gloves lost before committing a crime. Detectives can no longer use holofibers to confirm a Thief antag, but must instead rely on the fibers of the gloves around the crime scene. The addition of additional insuls colors means selecting yellow insulated gloves is no longer a safe option to blend in with all the other yellow gloves.
+
+## The Thief Kit Problem
+
+```admonish quote
+Seeing someone having an omega soap and assuming they therefore have a storage and DNA scramble implant
+```
+```admonish quote
+Seeing someone with a briefcase and concluding they are a thief
+```
+```admonish quote
+Knowing what thieves have in each kit
+```
+
+This issue is quite apparent and probably one of the easier ones to catch, but that doesn't mean it's any less annoying for Security who have to pretend that the Thief they caught don't have certain items. This is mostly only relevant to some sets; finding out someone has a Chameleon jumpsuit makes it only natural to further investigate and find the other Chameleon clothing.
+
+The kits that suffer the most from this issue are the following:
+- Chemistry Set
+ - Contains Omega Soap, Syringe, Ephedrine bottle. These could betray the Storage and DNA Scrambler Implants.
+- Syndie Set
+ - Contains Master At Arms hat and Interdyne Cigarettes. These could betray the Agent ID and Emag.
+- Sleeper Set
+ - Contains a Pyjama hat and Nitrous Oxide tank. These could betray the Hypopen. The jumpsuit isn't as big of an issue since it can be cut into cloth.
+- Communicator Set
+ - Contains a briefcase filled with a thief figurine, neck gater, tacticool jumpsuit and jensen coat. These could betray the Master Comms Key, CyberPen and Voicemask.
+
+### Proposed Solution
+
+Cull the unnecessary fluff items from the set and make them the same level of discoverability. If it's desirable to have the thief hide stuff, include that in the items being recieved; implants require the thief to hide the implanter for example. If the Communicator Set should require the thief to hide a fluff thief figurine for example, instead make the the Master Comms Key come in a box that needs to be hid.
+
+## The Disguised Items Problem
+
+There are many items in the game that are explicitly designed to look like and sometimes even act like another object. The degree of how effective this is depends on the object. They come in the following categories (some job items not listed):
+
+- Items that can't be found unless directly used
+ - Conducting Gloves
+ - Thieving Gloves
+ - Hypodart
+ - Decoy Nuclear Disk
+ - Explosive Banana
+ - Explosive Wet Floor Sign
+
+- Items that can be found if worn
+ - Voice Mask
+ - Chameleon Kit
+ - No-slip Shoes
+
+- Items that can be found if held
+ - Hypopen
+ - Stimkit
+ - Agent ID Card
+ - Lobbying Bundle
+ - Energy Dagger
+ - Cane Sword
+
+- Items that can be found if examined
+ - Extra-Bright Lantern
+ - Blue Boxing Gloves
+ - Dehydrated Space Carp
+
+There is a question to be made what the intended purpose of these disguises are. Something like the Extra-Bright Lantern can only survive a passing glance from crew, a cane sword may be found if an officer is searching thoroughly and a hypodart can't be determined to be a Syndicate object unless explicitly tested. The problem arises when Security is able to be too thorough with a search and find an item they aren't looking for, or when Security knows for certain an item is contraband but can't prove it.
+
+There is also an issue where these disguised items are unknown to crew (until an uplink is found), while the other "obvious" antag items are not. So [crew can have full knowledge](https://forum.spacestation14.com/t/what-is-a-syndicate-item/5363) of emags, webvests, e-swords and northstars, but not about hypopens or thieving gloves.
+
+### Proposed Solution
+
+This is probably the most comprehensive change and touches on things outside the stated problem above, in the interest of making a more streamlined system and help onboarding new players into contraband gameplay. My proposal is the following:
+
+- Rule change: Crew have knowledge about stealth items.
+- *Non-stealth* items can now be determined to be contraband upon being examined.
+ - Improvised contraband (improvised weapons, shivs, makeshift cuffs etc.) have the following text added: "This item is minor contraband."
+ - Items restricted to departments (insulated gloves, RCDs, scalpels, Security gear etc.) have the following text added: "This item is departmentally restricted."
+ - Command items (HoS' secret orders, Captain's Sabre, Nuke Disk, CE's boots etc.) have the following text added: "This item is restricted to Command."
+ - Syndicate items have the following text added: "This item is Syndicate contraband."
+- Note that the change above does not change the crime definitions in Space Law.
+- Most stealth items can now be locked to hide their functionality, making it act as a normal item. If the wearer/holder speaks a Traitor codeword, the functionality unlocks.
+ - While locked, the contraband examine text is not shown.
+ - Thieves get a single codeword, not shared by other thieves or traitors.
+ - Nukies get a set codeword "Syndicate".
+ - Note that this is not applicable for all items. For example, the Extra-Bright Lantern can not be locked, allowing it to only pass inspection at a glance.
+- Security has a new machine available roundstart, the **Contraband Scanner**.
+ - The device acts like an airport x-ray scanner, able to find hidden compartments and technologies in otherwise mundane items.
+ - An item can be placed inside the scanner. After six minutes the item comes out; if the item is of Syndicate origin, it is marked as such when examined: "This item is disguised Syndicate contraband".
+ - This mark can be cleaned off with soap.
+- Rule change: Security can only confiscate non-contraband items that they can confirm was used in a crime. Security can not keep an item from being returned to a crewmate on suspicion of it being contraband. Normal rules on Captain outlawing a specific item still apply.
+ - This is to ensure Security does not overextend and confiscate an unscanned stealth item.
+
+These changes do introduce a new rule, however it is also one that is very easy to enforce and check. It also frees up crew to speak plainly about stealth items in the same manner crew are able to talk and discuss Emags.
+
+Additionally, this change helps new Sec players recognize contraband. Security still have discretion to not confiscate certain contraband such as insulated gloves and some contraband (e.g. drugs) can't be marked; this just assists in informing players and Security alike what counts.
+
+## The Contraband Usage Problem
+
+While not a metaknowledge issue and more a balancing question, this issue was raised in discussion around this PR and heavily ties into the proposed changes.
+
+Security and Command are restricted from using Syndicate equipment via admin ruling. This is due to the strength Syndicate items has and the use of them would give Security/Command too much of an advantage when engaging with other antags. There are exceptions to this rule: most notably is the use of Syndicate comms keys, but only if the use is to listen in Syndicate communication (e.g. you wouldn't be able to use the Syndicate channel to have a private "exclusive Sec channel"). There is also an exception made for when the use of a Syndicate item is a necessity for survival and no other options are available, though where that line is drawn is highly contextual. That means any Security/Command use of a Syndicate item should be scrutinized by an admin, which adds to the workload and may lead well-intentioned players to be punished for misjudging what constitutes valid use.
+
+It's important to note that this limitation is only applied to Security and Command. Normal crew are allowed to use Syndicate items with no restrictions (self-antag rules still apply; having a C-20 does not mean you get to shoot your fellow crew with it).
+
+### Proposed Solution
+
+To reduce admin burden and make this balance design mechanically enforced rather than via rules, I propose the following:
+
+- Rule change: There is no rule limitation for Security/Command utilizing Syndicate equipment.
+- If a character has a **Mindshield implant**, some Syndicate items no longer become usable or have decreased functionality. The specifics depend on the item:
+ - Minor impact equipment like a Syndicate EVA suit or Jetpack could still be utilized by Mindshielded characters. These restriction-less items should have a crew equivalent or not provide any major benefit.
+ - Restricted items should ideally be able to be turned off by mindshielded characters, but not turned on/utilized. Examples:
+ - Emag: Unable to be used at all, all interactions providing a pop-up that the implant stops your character from using it.
+ - C-20: Unable to be fired, though can still be reloaded/emptied of its mag. Trying to pull the trigger provides a pop-up that the implant stops your character from using it.
+ - PDA Uplink: Can be opened and scrolled through, but all purchase buttons are grayed out. TC can still be removed/inserted.
+ - Radio Jammer: Can be turned off but not turned on. Battery can be removed/replaced.
+ - Stimpack / Combat Syringe: Can not be injected into or by a mindshielded character.
+- Mindshield implants can not be removed from Security / Command crew (e.g. roundstart Mindshielded roles), but can be removed from normal crew/Syndicates who have been Mindshielded during the round.
+- There may be rules required that Security can not hand out Syndicate items to crew or have a crewmate use a Syndicate item on Security's command. This depends on whether abusing the items like this is feasible in practice.
+
+Not only does this solution tie in to the existing Mindshield system, but also makes Mindshield implants relevant to be used on crew during non-Rev rounds. This does come with the added danger of mindshielded Syndicates being able to pass as Security / Command, but at the same time with the benefit of knowing anyone Mindshielded is limited in using Syndicate items.
+
+## Other Problems that have PRs in the works
+
+### Roundtype problem
+```admonish quote
+Preparing for Nukies just because no antag activity has happened a while into the round.
+```
+```admonish quote
+"Quiet shift today"
+```
+```admonish quote
+"I found a cobra or some other syndicate tech on station/a syndicate has done something noticable. Main round antag is traitors."
+```
+```admonish quote
+"It's been strangely quiet and nothing has really happened in the first 30 minutes. Probably nukies"
+```
+Can be solved by adding single Traitors to non-Traitor gamemodes: https://github.com/space-wizards/space-station-14/pull/27501
+
+### Map loot problem
+```admonish quote
+Every instance of Gamer Loot in the walls
+```
+```admonish quote
+Powergaming for maints loot
+```
+Can be solved by making map loot spawn randomly: https://github.com/space-wizards/space-station-14/pull/27082
+
+### Overly suspicious players
+```admonish quote
+"I heard a flash somehwe near security, it must be revs! Cargo buy mindshields immediately"
+```
+```admonish quote
+YOOOOOOO YA WANT A STAMP FOR SOMETING NOT THAT IMPORTANT?, YA GONNA USE CYBERSUN PEN FOR EDITING THE PAPER!!, KOS
+```
+Can be solved by having a non-antag role mimicing antag behavior: https://github.com/space-wizards/docs/pull/129
+
From 4fca4659a139b82479ee8d1cb4e927af64afbbb6 Mon Sep 17 00:00:00 2001
From: Kara
Date: Fri, 31 May 2024 13:12:38 -0700
Subject: [PATCH 53/80] Update basic-networking-and-you.md
remove access markers on ID comp, probably just serves to confuse people reading it when we're focussing on the network part
---
src/en/ss14-by-example/basic-networking-and-you.md | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/en/ss14-by-example/basic-networking-and-you.md b/src/en/ss14-by-example/basic-networking-and-you.md
index 4e2584712..e0b41875e 100644
--- a/src/en/ss14-by-example/basic-networking-and-you.md
+++ b/src/en/ss14-by-example/basic-networking-and-you.md
@@ -31,13 +31,10 @@ An example of all of the networking code required for IDCardComponent now, from
// IDCardComponent.cs
[RegisterComponent, NetworkedComponent]
[AutoGenerateComponentState]
-[Access(typeof(SharedIdCardSystem), typeof(SharedPDASystem), typeof(SharedAgentIdCardSystem))]
public sealed partial class IdCardComponent : Component
{
[DataField]
[AutoNetworkedField]
- [Access(typeof(SharedIdCardSystem), typeof(SharedPDASystem), typeof(SharedAgentIdCardSystem),
- Other = AccessPermissions.ReadWrite)] // FIXME Friends
public string? FullName;
[DataField]
From 97edb3410a168755640ab544218f05e00be919ac Mon Sep 17 00:00:00 2001
From: Kara
Date: Fri, 31 May 2024 14:30:00 -0700
Subject: [PATCH 54/80] Update README.md as we've moved away from wikijs for a
long time at this point
---
README.md | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/README.md b/README.md
index b507cdb27..25488b261 100644
--- a/README.md
+++ b/README.md
@@ -1,12 +1,14 @@
# Space Wizards Development Wiki
-This is a port of the old Wiki.js SS14 documentation to `mdbook`, for the following benefits:
+This is the `mdbook`-based developer documentation for all Space Wizards projects, including Robust Toolbox, Space Station 14, the SS14 launcher, etc. These docs cover many topics and can be potentially very useful for mappers, spriters, active contributors & prospective contributors, people who want to use our engine for their own projects, fork developers, and so on.
+
+The site is currently hosted at [https://docs.spacestation14.com](https://docs.spacestation14.com).
+
+Benefits of the current docs site infrastructure include:
- First-class git support, open source and actually editable by everyone
-- No webshit bloat, much faster in general
-- More familiar & comfortable for developers since `mdbook` use is very widespread
-- No sign-on infrastructure or hosting necessary (besides GH pages)
-- More customizable
-- Friction to editing reduced significantly
+- Decently familiar & comfortable for developers since `mdbook` use is very widespread
+- No sign-on infrastructure or hosting necessary (besides GH pages), if forks would like to host their own
+- Very low friction to adding new pages and editing/fixing old ones
- Eventual localization support
The following `mdbook` features & plugins are available and in use:
@@ -18,8 +20,6 @@ The following `mdbook` features & plugins are available and in use:
- `mdbook-admonish`
- `mdbook-emojicodes`
-The site is currently hosted at [https://docs.spacestation14.com](https://docs.spacestation14.com).
-
**For information such as how to edit, build & test these docs, see [Guide to Editing Docs](https://spacestation14.io/docs/en/meta/guide-to-editing-docs.html). on the site itself** (or [in this repo](./src/en/meta/guide-to-editing-docs.md))
## Screenshots
From 5441bd17fa4aa58279841ea2725e2719a29bcff9 Mon Sep 17 00:00:00 2001
From: Kara
Date: Fri, 31 May 2024 14:31:02 -0700
Subject: [PATCH 55/80] Update README.md
---
README.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/README.md b/README.md
index 25488b261..1fc0fa92c 100644
--- a/README.md
+++ b/README.md
@@ -9,6 +9,7 @@ Benefits of the current docs site infrastructure include:
- Decently familiar & comfortable for developers since `mdbook` use is very widespread
- No sign-on infrastructure or hosting necessary (besides GH pages), if forks would like to host their own
- Very low friction to adding new pages and editing/fixing old ones
+- High level of customizability with styling and easy custom scripting
- Eventual localization support
The following `mdbook` features & plugins are available and in use:
From 810cc994be30bcbfe116aa3a37994e631dbbd630 Mon Sep 17 00:00:00 2001
From: Nemanja <98561806+EmoGarbage404@users.noreply.github.com>
Date: Sat, 1 Jun 2024 22:57:40 -0400
Subject: [PATCH 56/80] Art Guidelines (#225)
mythical doc ive been sitting on for ages
could do with some pics but i do what i can
---------
Co-authored-by: Kara
---
src/en/space-station-14/art.md | 237 ++++++++++++++++++++++++++++++++-
1 file changed, 234 insertions(+), 3 deletions(-)
diff --git a/src/en/space-station-14/art.md b/src/en/space-station-14/art.md
index 77a4a28b9..288fdb84e 100644
--- a/src/en/space-station-14/art.md
+++ b/src/en/space-station-14/art.md
@@ -1,5 +1,236 @@
# Art
-```admonish warning "Attention: Placeholder!"
-This section is a placeholder, pending a design-doc being created by the related work-group
-```
\ No newline at end of file
+```admonish warning "Disclaimer"
+Keep in mind, all of these rules are general guidelines.
+A sprite can look good and fit well even if it doesn't necessarily follow all of these guidelines to the letter.
+
+These are meant primarily as a resource for new contributors to understand the general aspects that they should be shooting for.
+This isn't the stick by which to measure all new or existing art.
+You shouldn't be modifying perfectly good sprites solely to shift them from one perspective to another or just to reduce the color count.
+
+These aren't metrics for measuring the objective quality of art, but rather just notes for keeping consistency within the game's visual style.
+```
+
+## Theme & Style
+
+### Keep it Grounded
+* Although SS14 takes place in the future, the general aesthetic is far from the extravagant techno-elegance of a lot of modern Sci-fi.
+Common household items and machines shouldn't look very different from what we have today.
+
+
+* Keeping designs simple is completely fine.
+If you're depicting a simple box or desk object, don't fall into the trap of over-detailing your sprite with bolts, lights, and various technological stigmata.
+Some things just look dull, and that's OK!
+
+
+* It's okay to reference other media in terms of art.
+Lots of antagonists and designs take strong inspiration from TV shows, other games, and movies.
+However, **keep references subtle**!
+They shouldn't stick out an inordinate amount and shouldn't be commonly found.
+If someone can identify an obvious pop culture reference, it should be fairly rare so as to not distract from the tone and atmosphere.
+
+### Contrast Between Boring and Fantastical
+* While many elements of SS14 are quite grounded and boring, there are many different fantastical things as well.
+For these rarer and more less realistic things, playing up the relative different to the surrounding is important.
+This is a large part in the comedic tone of SS14.
+* * A wizard in a tower can be sagely and wise, but a wizard waiting to pick up his mail plays into absurdist humor in a beneficial way.
+* * A gross or weird alien can be emphasized through contrast with the environment.
+This aids in depicting futuristic items, as they appear even more advanced through their contrast with the things around them.
+
+
+* When creating art for extremely fantastical or out of place things, it may be beneficial to intentionally push the style.
+Using especially vibrant colors or baking in glows into the sprite can give extra emphasis to something that _should_ look out of place.
+
+### The Future Never Looked so Old
+* While the setting is unquestionably in the future, the aesthetics of SS14 commonly and routinely reference older technology.
+The station is lit with buzzing incandescent bulbs, people send faxes to one another, and computers are still fat consoles with big glass screens.
+This retro appearance is an important factor of the visual identity of SS14: _embrace it_.
+
+
+* When creating new assets or features, playing on existing real world technology can create an intuitive understanding.
+Instead of depicting some kind of generic 'credit chip,' using paper bills is immediately recognizable.
+If you're trying to communicate the purpose of something, creating a visual association with something the player is likely familiar with can help them intuitively understand its function.
+* * If you're make a sci-fi generator, making it look similar to a real-life generator helps people understand it without close examination.
+* * Don't worry about the logistical side of retro technology.
+Any amount of ancient tech can be hand-waved away with budget restrictions and lazy scientists.
+Adhering to a personal concept of lore is secondary to serving the style.
+
+### Readability and Game Sprites
+
+* Keep the size of assets **proportional** to similar objects.
+Obviously items will look over-sized compared to mobs, but making sure that the entire canvas isn't filled by a small object helps establish a relative scale.
+It can be confusing when an item that looks small when held appears significantly larger when dropped to the ground.
+
+
+* **Clothing** shouldn't cover excessive amounts of a mob or areas that shouldn't be covered by that region.
+Glasses shouldn't engulf an entire head and a hat shouldn't come down to the shoulders.
+Clothing should ideally have minimal overlap with other items so as to reduce visual clutter when many items are worn.
+
+
+* Mobs and direction-sensitive structures should contain **directional sprites** (directionals) for all 4 cardinal directions.
+When making directionals, the height of the asset should remain relatively constant and all details should be preserved for a consistent visual shape.
+Likewise, the color and placement of shadows should also shift to better depict the item turning in 3D space.
+
+## Technique
+
+### Perspective
+
+* **Structures** in the game world should be in a 3/4 perspective.
+This includes various machines, furniture, and decor.
+A 3/4's perspective means that they are angled straight forward with the viewer looking down on them from above.
+This gives you a clear view of the top as well as the front of the object.
+
+
+* **Mobs**, **clothing**, and **items** are rendered in a flat perspective.
+A flat perspective can be thought of as looking at the image straight-on at eye level.
+This maximizes detail while minimizing any perspective-based distortion.
+When perspective is necessary for conveying something properly, use 3/4s.
+
+
+* **Floor tiles** and **ground** textures similarly lack any particular perspective.
+The actual floor itself should be a simple birds-eye perspective but any small detailing like stones or pits can employ a more conventional flat perspective.
+
+
+* **Walls** and wall-like structures (windows, grilles, etc.) are rendered in a exaggerated top-down style typically referred to as _classic_.
+Walls shouldn't have any kind of 3/4 perspective and, while the sides may be technically visible, the focus is on the "top" of the wall.
+This isn't to say you're seeing inside of the wall into some kind of inner lattice structure, but rather it's more of a flat texture.
+Walls are very difficult and strange in their form so it's best to just look at existing walls for inspiration.
+
+
+* Similarly, **wall-mounted structures** are additionally rendered in a flat perspective.
+This is most visible in things like posters and aids in readability.
+
+### Color
+* Avoid many overlapping palettes, or _gradients_ of many similar colors, prefer small, distinct palettes.
+Make sure the individual colors in a sprite have enough contrast to be discerned in game.
+Remember, sprites in game are a lot smaller than your editor: err on the side of high-contrast.
+
+```admonish info "Noise"
+Noise and other similar effects can be valuable for adding texture to an image.
+Don't be afraid of including mild noise or texture into a sprite!
+Use multiple layers to be able to compare and reverse changes easily.
+```
+
+* Try not to go overboard with too many different hues.
+Sticking with a few primary tones (_department colors are a good use for this!_) and accenting them with neutral tones helps create a cohesive asset that doesn't look busy.
+
+
+* Don't use **darken**, **burn**, or **gradient** tools for half-tones when shading.
+Darker shades of color should be intentionally chosen from your palette.
+Using gradients of color can make sprites look muddy and make them difficult to edit in the future.
+
+
+* Don't overuse **hue-shifting** when creating shades for your palette.
+Using it sparingly can lend greater intensity to your darker tones, but overuse can create an overly cartoonish appearance that looks overly fantastical.
+The color of an object should still read clearly when shifting is applied:
+* * An apple should be red, not a deep magenta
+* * A blue shirt shouldn't be a deep purple in its shadows
+* * Regular industrial steel shouldn't be tinted cyan and blue
+
+### Lighting
+* Sprites are usually lit from the **top**.
+For standalone object sprites, the light source may be slightly angled to either side, but generally a centered light from above is how most sprites are lit.
+
+
+* Avoid **high-contrast** lighting.
+Although the primary light source is coming from the top, make sure the ambient light is accounted for.
+Objects should be lit in the context of being in a _well-lit room_.
+Shadows shouldn't be pitch black and highlights shouldn't be bone white.
+
+
+* Be mindful of the **luster** of a surface when adding lighting to your sprite.
+How shiny is your material?
+Cloth surfaces are generally quite matte whereas metal usually has long reflections along its length.
+Make sure the amount and contrast of the lighting being applied is appropriate for the surface being depicted.
+* * Applying a uniformly glossy lighting across lots of sprites can lead to a 'buttery' appearance that harms readability.
+* * Less is more!
+A simple sprite with minimal lighting is preferable to an over-worked sprite that reads poorly and sticks out.
+
+
+* Keep lights **temperature neutral**.
+This relates a lot to the earlier point on hue-shifting.
+Baking shadows with purple tints gives the impression of _blue ambient light_, when it's largely the opposite!
+Keeping the temperature largely neutral ensures that when colored lighting does appear in game, it doesn't clash and creates weird tones.
+
+### Outlines
+* All sprites should have **colored outlines** around them.
+This helps improve readability in the world and clarify the forms.
+Make sure that the outline is colored according to the section it surrounds, instead of being a single flat color.
+* * Outlining an entire sprite in black often looks plain and amateurish.
+Using multiple colors in your outline gives a much better result.
+
+
+* Don't include shading on your outlines.
+The value of the outline should be consistent across the entire shape.
+
+
+### Miscellaneous
+
+* **Center** sprites within the canvas.
+This helps massively when displayed in-hand or inside the UI.
+
+
+* Avoid **anti-aliasing**, as this creates muddy edges and transparencies that look ugly and mess with the interaction outline shader.
+Anti-aliasing artifacts are extremely pronounced at a low resolution.
+
+## Technical Info
+
+### Size
+* The vast majority of Sprites are **32x32** pixels in size.
+This is the size of a single in-game tile.
+When making multi-tile sized objects or machines, you may need to adjust the sprite's size to 64x64 or even larger (note that the meta.json in the RSI will need to be adjusted to account for this).
+
+
+* When it's necessary to mix sprite sizes, such as using 64x64 pixel inhands for particularly large items, simply make a separate RSI with the same name and the `_64x` suffix in order to denote the relationship between the two.
+
+
+* Do not use `SpriteComponent.Scale` to increase the fidelity of sprites.
+A 64x64 sprite with a "0.5, 0.5" scalar factor applied will indeed be equally sized to a 32x32 sprite but with increased resolution.
+However, the mixing of pixel sizes looks extremely messy and with certain settings is completely unreadable.
+
+
+* Similarly, avoid the use of `SpriteComponent` scaling in order to depict size.
+Either respriting to a smaller size or using technical elements that preserve the size of individual pixels (displacement maps) are far better method for portraying size.
+
+
+### Licensing
+* the `meta.json` file requires the author to supply both a license and a copyright.
+The copyright is simply the provenance of the art within the file, specifying the specific codebase and commit that the asset was taken from.
+The license is a specific copyright license used for assets.
+
+
+* The following are valid licenses for the project: "CC-BY-3.0",
+ `CC-BY-4.0`,
+ `CC-BY-SA-3.0`,
+ `CC-BY-SA-4.0`,
+ `CC-BY-NC-3.0`,
+ `CC-BY-NC-4.0`,
+ `CC-BY-NC-SA-3.0`,
+ `CC-BY-NC-SA-4.0`,
+ `CC0-1.0`
+* * `CC0-1.0` denotes public domain assets.
+* * Assets with the `BY` discriminator must be attributed.
+* * Assets with the `NC` discriminator denote non-commercial assets.
+**WARNING: These assets may be disallowed from use in the repo in the future.**
+Use NC assets sparingly.
+* * Assets with the `SA` discriminator are share-alike and must be distributed under the same license.
+
+
+* When porting assets from SS13 servers, it's important to check and preserve the license that the sprites are coming from.
+This information typically isn't readily available, but it can usually be found in the README.txt file for the project.
+* * When in doubt about the ability to use a file, try joining the discord and asking.
+
+
+### Miscellaneous
+
+* Make sure all images are encoded in RGB color.
+Using indexed color or grayscale color encoding can make it difficult to modify assets in the future.
+
+
+* Keep RSIs as generally limited as possible.
+An RSI should be all the appropriate sprites for a general object.
+Multiple variations of an object are fine (different versions of an ID card), but refrain from creating overly large RSIs with 30+ files in them.
+
+
+* When appropriate, split up sprites into layers and use visualizers to enable changes.
+You don't need to create multiple sprites for every combo of open door when you can just have separate open door layers and other layers that work independently.
From d83bdd4809144f8b7098862d45010309dc8cc361 Mon Sep 17 00:00:00 2001
From: Jezithyr
Date: Sat, 1 Jun 2024 20:22:48 -0700
Subject: [PATCH 57/80] Setup templates for department design docs (#230)
Added design doc templates for department design docs
and added a description for what a department is in the department doc
---
src/SUMMARY.md | 2 +-
src/en/space-station-14/accessibility.md | 6 +--
src/en/space-station-14/admin-tools.md | 6 +--
src/en/space-station-14/characters-species.md | 6 +--
src/en/space-station-14/combat.md | 6 +--
.../core-design/departments.md | 1 -
src/en/space-station-14/departments.md | 21 +++++++--
src/en/space-station-14/departments/atmos.md | 44 ++++++++++++++++--
.../departments/cargo-salvage.md | 45 +++++++++++++++++--
.../space-station-14/departments/command.md | 44 ++++++++++++++++--
.../departments/engineering.md | 44 ++++++++++++++++--
.../space-station-14/departments/medical.md | 44 ++++++++++++++++--
.../space-station-14/departments/science.md | 44 ++++++++++++++++--
.../space-station-14/departments/security.md | 44 ++++++++++++++++--
.../space-station-14/departments/service.md | 44 ++++++++++++++++--
src/en/space-station-14/mapping.md | 6 +--
src/en/space-station-14/player-interaction.md | 7 ++-
src/en/space-station-14/roleplay-lore.md | 6 +--
src/en/space-station-14/round-flow.md | 6 +--
src/en/space-station-14/user-interface.md | 6 +--
20 files changed, 374 insertions(+), 58 deletions(-)
delete mode 100644 src/en/space-station-14/core-design/departments.md
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 599757f8f..ec89ddad9 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -190,7 +190,7 @@ Space Station 14
- [Proposals]()
- [Stat Panels](en/space-station-14/user-interface/proposals/statpanels.md)
-- [Departments](en/space-station-14/core-design/departments.md)
+- [Departments](en/space-station-14/departments.md)
- [Atmos](en/space-station-14/departments/atmos.md)
- [PR Guidelines](en/space-station-14/departments/atmos/guidelines.md)
diff --git a/src/en/space-station-14/accessibility.md b/src/en/space-station-14/accessibility.md
index c67b651d0..a8bf730fd 100644
--- a/src/en/space-station-14/accessibility.md
+++ b/src/en/space-station-14/accessibility.md
@@ -1,5 +1,5 @@
-# Accessibility
-
```admonish warning "Attention: Placeholder!"
This section is a placeholder, pending a design-doc being created by the related work-group
-```
\ No newline at end of file
+```
+
+# Accessibility
diff --git a/src/en/space-station-14/admin-tools.md b/src/en/space-station-14/admin-tools.md
index bb9bed46f..29f5b4c89 100644
--- a/src/en/space-station-14/admin-tools.md
+++ b/src/en/space-station-14/admin-tools.md
@@ -1,5 +1,5 @@
-# Admin Tooling
-
```admonish warning "Attention: Placeholder!"
This section is a placeholder, pending a design-doc being created by the related work-group
-```
\ No newline at end of file
+```
+
+# Admin Tooling
diff --git a/src/en/space-station-14/characters-species.md b/src/en/space-station-14/characters-species.md
index 2e851b96e..92f297b2e 100644
--- a/src/en/space-station-14/characters-species.md
+++ b/src/en/space-station-14/characters-species.md
@@ -1,5 +1,5 @@
-# Character/Species
-
```admonish warning "Attention: Placeholder!"
This section is a placeholder, pending a design-doc being created by the related work-group
-```
\ No newline at end of file
+```
+
+# Character/Species
diff --git a/src/en/space-station-14/combat.md b/src/en/space-station-14/combat.md
index 96fd96290..e1e88734a 100644
--- a/src/en/space-station-14/combat.md
+++ b/src/en/space-station-14/combat.md
@@ -1,5 +1,5 @@
-# Combat
-
```admonish warning "Attention: Placeholder!"
This section is a placeholder, pending a design-doc being created by the related work-group
-```
\ No newline at end of file
+```
+
+# Combat
diff --git a/src/en/space-station-14/core-design/departments.md b/src/en/space-station-14/core-design/departments.md
deleted file mode 100644
index 3dc8758ec..000000000
--- a/src/en/space-station-14/core-design/departments.md
+++ /dev/null
@@ -1 +0,0 @@
-# Departments
diff --git a/src/en/space-station-14/departments.md b/src/en/space-station-14/departments.md
index f0b07a653..eb2f22721 100644
--- a/src/en/space-station-14/departments.md
+++ b/src/en/space-station-14/departments.md
@@ -1,6 +1,19 @@
+```admonish warning "Attention: Work in Progress!"
+This section is a work in progress, additional detail will be added
+```
+
# Departments
-```admonish warning "Attention: Placeholder!"
-This section is a placeholder, pending a design-doc being created by the related work-group
-```
-a department is a series of tubes
\ No newline at end of file
+Departments are categories that represent a specific type of gameplay. Each department has a clear area of relevance, for example: Engineering's gameplay focuses primarily on maintenance, repair and construction while security focuses on maintaining station order and responding to threats to the station/crew.
+
+
+
+## Gameplay Fantasy/Role
+
+Departments have a clear "fantasy" when it comes to gameplay, for engineering this might be working as an engineer and solving practical problems related to the powergrid while for service it might be running a texas style bar on the frontiers of space, serving drinks and racking your shotgun at troublemakers.
+
+## Department Mechanics
+
+A department's core mechanics should reinforce/enable this fantasy while also allowing for fun interactions with other departments and players. Each department has it's own design doc complete with gameplay pillars to outline what sort of gameplay is the focus of that department.
+
+There can be some level of overlap between game mechanics between departments (such as with medical treatments), but a department-specific mechanic should primarily be interacted with by players of that department during regular gameplay.
diff --git a/src/en/space-station-14/departments/atmos.md b/src/en/space-station-14/departments/atmos.md
index 78fa0f7e1..830937d51 100644
--- a/src/en/space-station-14/departments/atmos.md
+++ b/src/en/space-station-14/departments/atmos.md
@@ -1,5 +1,43 @@
-# Atmos
-
```admonish warning "Attention: Placeholder!"
This section is a placeholder, pending a design-doc being created by the related work-group
-```
\ No newline at end of file
+```
+
+# Atmos
+The life-blood of the station
+
+## Concept
+> A high-level conceptual overview of what this department does. This is generally 1-2 paragraphs and should reflect a high level view of what this department brings to the player and the game.
+
+## Player Story
+> 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.
+
+## Design Pillars
+> 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.
+
+> 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.
+
+> 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.
+
+### Pillar_1:
+ > Breif Pillar Description
+
+ ### Pillar_2:
+ > Breif Pillar Description
+
+## Objectives
+> 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?
+
+## Progression
+> 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?
+
+## Flow
+> 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?
+
+## Mechanics
+> What major mechanics does this department use and how are they connected to this department.
+
+### Mechanic_Placeholder1
+> 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.
+
+### Mechanic_Placeholder2 (Not Implemented Yet)
+> Mechanics that are unimplemented should be marked with (Not Implmented Yet) and should link the associated design proposal if it exists.
\ No newline at end of file
diff --git a/src/en/space-station-14/departments/cargo-salvage.md b/src/en/space-station-14/departments/cargo-salvage.md
index 9e63e7b9e..feded1735 100644
--- a/src/en/space-station-14/departments/cargo-salvage.md
+++ b/src/en/space-station-14/departments/cargo-salvage.md
@@ -1,5 +1,44 @@
-# Cargo/Salvage
-
```admonish warning "Attention: Placeholder!"
This section is a placeholder, pending a design-doc being created by the related work-group
-```
\ No newline at end of file
+```
+
+# Cargo/Salvage
+~~cargonia~~ shipping and receiving
+
+
+## Concept
+> A high-level conceptual overview of what this department does. This is generally 1-2 paragraphs and should reflect a high level view of what this department brings to the player and the game.
+
+## Player Story
+> 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.
+
+## Design Pillars
+> 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.
+
+> 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.
+
+> 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.
+
+### Pillar_1:
+ > Breif Pillar Description
+
+ ### Pillar_2:
+ > Breif Pillar Description
+
+## Objectives
+> 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?
+
+## Progression
+> 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?
+
+## Flow
+> 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?
+
+## Mechanics
+> What major mechanics does this department use and how are they connected to this department.
+
+### Mechanic_Placeholder1
+> 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.
+
+### Mechanic_Placeholder2 (Not Implemented Yet)
+> Mechanics that are unimplemented should be marked with (Not Implmented Yet) and should link the associated design proposal if it exists.
\ No newline at end of file
diff --git a/src/en/space-station-14/departments/command.md b/src/en/space-station-14/departments/command.md
index 1a9998fe5..a9356e614 100644
--- a/src/en/space-station-14/departments/command.md
+++ b/src/en/space-station-14/departments/command.md
@@ -1,5 +1,43 @@
-# Command
-
```admonish warning "Attention: Placeholder!"
This section is a placeholder, pending a design-doc being created by the related work-group
-```
\ No newline at end of file
+```
+
+# Command
+the ~~highly incomponent~~ people in charge
+
+## Concept
+> A high-level conceptual overview of what this department does. This is generally 1-2 paragraphs and should reflect a high level view of what this department brings to the player and the game.
+
+## Player Story
+> 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.
+
+## Design Pillars
+> 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.
+
+> 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.
+
+> 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.
+
+### Pillar_1:
+ > Breif Pillar Description
+
+ ### Pillar_2:
+ > Breif Pillar Description
+
+## Objectives
+> 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?
+
+## Progression
+> 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?
+
+## Flow
+> 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?
+
+## Mechanics
+> What major mechanics does this department use and how are they connected to this department.
+
+### Mechanic_Placeholder1
+> 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.
+
+### Mechanic_Placeholder2 (Not Implemented Yet)
+> Mechanics that are unimplemented should be marked with (Not Implmented Yet) and should link the associated design proposal if it exists.
\ No newline at end of file
diff --git a/src/en/space-station-14/departments/engineering.md b/src/en/space-station-14/departments/engineering.md
index 6f46533a6..b7e5f7232 100644
--- a/src/en/space-station-14/departments/engineering.md
+++ b/src/en/space-station-14/departments/engineering.md
@@ -1,5 +1,43 @@
-# Engineering
-
```admonish warning "Attention: Placeholder!"
This section is a placeholder, pending a design-doc being created by the related work-group
-```
\ No newline at end of file
+```
+
+# Engineering
+The powerhouse of the ~~cell~~ station
+
+## Concept
+> A high-level conceptual overview of what this department does. This is generally 1-2 paragraphs and should reflect a high level view of what this department brings to the player and the game.
+
+## Player Story
+> 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.
+
+## Design Pillars
+> 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.
+
+> 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.
+
+> 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.
+
+### Pillar_1:
+ > Breif Pillar Description
+
+ ### Pillar_2:
+ > Breif Pillar Description
+
+## Objectives
+> 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?
+
+## Progression
+> 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?
+
+## Flow
+> 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?
+
+## Mechanics
+> What major mechanics does this department use and how are they connected to this department.
+
+### Mechanic_Placeholder1
+> 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.
+
+### Mechanic_Placeholder2 (Not Implemented Yet)
+> Mechanics that are unimplemented should be marked with (Not Implmented Yet) and should link the associated design proposal if it exists.
\ No newline at end of file
diff --git a/src/en/space-station-14/departments/medical.md b/src/en/space-station-14/departments/medical.md
index 8cb78ad19..cd7fcda2a 100644
--- a/src/en/space-station-14/departments/medical.md
+++ b/src/en/space-station-14/departments/medical.md
@@ -1,5 +1,43 @@
-# Medical
-
```admonish warning "Attention: Placeholder!"
This section is a placeholder, pending a design-doc being created by the related work-group
-```
\ No newline at end of file
+```
+
+# Medical
+Responsible for causing patient's skeletons to disappear
+
+## Concept
+> A high-level conceptual overview of what this department does. This is generally 1-2 paragraphs and should reflect a high level view of what this department brings to the player and the game.
+
+## Player Story
+> 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.
+
+## Design Pillars
+> 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.
+
+> 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.
+
+> 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.
+
+### Pillar_1:
+ > Breif Pillar Description
+
+ ### Pillar_2:
+ > Breif Pillar Description
+
+## Objectives
+> 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?
+
+## Progression
+> 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?
+
+## Flow
+> 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?
+
+## Mechanics
+> What major mechanics does this department use and how are they connected to this department.
+
+### Mechanic_Placeholder1
+> 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.
+
+### Mechanic_Placeholder2 (Not Implemented Yet)
+> Mechanics that are unimplemented should be marked with (Not Implmented Yet) and should link the associated design proposal if it exists.
\ No newline at end of file
diff --git a/src/en/space-station-14/departments/science.md b/src/en/space-station-14/departments/science.md
index 22a6cad81..3b3366b9f 100644
--- a/src/en/space-station-14/departments/science.md
+++ b/src/en/space-station-14/departments/science.md
@@ -1,5 +1,43 @@
-# Science
-
```admonish warning "Attention: Placeholder!"
This section is a placeholder, pending a design-doc being created by the related work-group
-```
\ No newline at end of file
+```
+
+# Science
+THE SCIENCE TEAM
+
+## Concept
+> A high-level conceptual overview of what this department does. This is generally 1-2 paragraphs and should reflect a high level view of what this department brings to the player and the game.
+
+## Player Story
+> 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.
+
+## Design Pillars
+> 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.
+
+> 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.
+
+> 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.
+
+### Pillar_1:
+ > Breif Pillar Description
+
+ ### Pillar_2:
+ > Breif Pillar Description
+
+## Objectives
+> 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?
+
+## Progression
+> 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?
+
+## Flow
+> 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?
+
+## Mechanics
+> What major mechanics does this department use and how are they connected to this department.
+
+### Mechanic_Placeholder1
+> 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.
+
+### Mechanic_Placeholder2 (Not Implemented Yet)
+> Mechanics that are unimplemented should be marked with (Not Implmented Yet) and should link the associated design proposal if it exists.
\ No newline at end of file
diff --git a/src/en/space-station-14/departments/security.md b/src/en/space-station-14/departments/security.md
index 7a31b9a9e..6e179c4c0 100644
--- a/src/en/space-station-14/departments/security.md
+++ b/src/en/space-station-14/departments/security.md
@@ -1,5 +1,43 @@
-# Security
-
```admonish warning "Attention: Placeholder!"
This section is a placeholder, pending a design-doc being created by the related work-group
-```
\ No newline at end of file
+```
+
+# Security
+SpaceCops... Bad boys, bad boys, whatcha gonna do when they come for you...
+
+## Concept
+> A high-level conceptual overview of what this department does. This is generally 1-2 paragraphs and should reflect a high level view of what this department brings to the player and the game.
+
+## Player Story
+> 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.
+
+## Design Pillars
+> 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.
+
+> 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.
+
+> 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.
+
+### Pillar_1:
+ > Breif Pillar Description
+
+ ### Pillar_2:
+ > Breif Pillar Description
+
+## Objectives
+> 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?
+
+## Progression
+> 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?
+
+## Flow
+> 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?
+
+## Mechanics
+> What major mechanics does this department use and how are they connected to this department.
+
+### Mechanic_Placeholder1
+> 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.
+
+### Mechanic_Placeholder2 (Not Implemented Yet)
+> Mechanics that are unimplemented should be marked with (Not Implmented Yet) and should link the associated design proposal if it exists.
\ No newline at end of file
diff --git a/src/en/space-station-14/departments/service.md b/src/en/space-station-14/departments/service.md
index 7baad5027..5db124e1d 100644
--- a/src/en/space-station-14/departments/service.md
+++ b/src/en/space-station-14/departments/service.md
@@ -1,5 +1,43 @@
-# Service
-
```admonish warning "Attention: Placeholder!"
This section is a placeholder, pending a design-doc being created by the related work-group
-```
\ No newline at end of file
+```
+
+# Service
+Serving drinks with a smile since 3521
+
+## Concept
+> A high-level conceptual overview of what this department does. This is generally 1-2 paragraphs and should reflect a high level view of what this department brings to the player and the game.
+
+## Player Story
+> 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.
+
+## Design Pillars
+> 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.
+
+> 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.
+
+> 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.
+
+### Pillar_1:
+ > Breif Pillar Description
+
+ ### Pillar_2:
+ > Breif Pillar Description
+
+## Objectives
+> 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?
+
+## Progression
+> 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?
+
+## Flow
+> 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?
+
+## Mechanics
+> What major mechanics does this department use and how are they connected to this department.
+
+### Mechanic_Placeholder1
+> 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.
+
+### Mechanic_Placeholder2 (Not Implemented Yet)
+> Mechanics that are unimplemented should be marked with (Not Implmented Yet) and should link the associated design proposal if it exists.
\ No newline at end of file
diff --git a/src/en/space-station-14/mapping.md b/src/en/space-station-14/mapping.md
index 74fb51355..ec6d8dfd3 100644
--- a/src/en/space-station-14/mapping.md
+++ b/src/en/space-station-14/mapping.md
@@ -1,5 +1,5 @@
-# Mapping
-
```admonish warning "Attention: Placeholder!"
This section is a placeholder, pending a design-doc being created by the related work-group
-```
\ No newline at end of file
+```
+
+# Mapping
diff --git a/src/en/space-station-14/player-interaction.md b/src/en/space-station-14/player-interaction.md
index d39dd87b3..f098fafb3 100644
--- a/src/en/space-station-14/player-interaction.md
+++ b/src/en/space-station-14/player-interaction.md
@@ -1,8 +1,7 @@
-# Player Interactions
-
```admonish warning "Attention: Placeholder!"
This section is a placeholder, pending a design-doc being created by the related work-group
```
+# Player Interactions
-## Systems/Mechanics related to common player interactions that are not department specific
-Examples of this would be underlying systems such as: Verbs, Doafters, PDAs, etc.
\ No newline at end of file
+## Systems/Mechanics related to common player interactions that are not department specific, if it's not specific to players then it belongs in Core Tech
+Examples of player interactions would be underlying systems such as: Verbs, Doafters, PDAs, etc.
\ No newline at end of file
diff --git a/src/en/space-station-14/roleplay-lore.md b/src/en/space-station-14/roleplay-lore.md
index 3235be631..499079e8d 100644
--- a/src/en/space-station-14/roleplay-lore.md
+++ b/src/en/space-station-14/roleplay-lore.md
@@ -1,5 +1,5 @@
-# Roleplay/Lore
-
```admonish warning "Attention: Placeholder!"
This section is a placeholder, pending a design-doc being created by the related work-group
-```
\ No newline at end of file
+```
+
+# Roleplay/Lore
diff --git a/src/en/space-station-14/round-flow.md b/src/en/space-station-14/round-flow.md
index 1844af814..c846ffb04 100644
--- a/src/en/space-station-14/round-flow.md
+++ b/src/en/space-station-14/round-flow.md
@@ -1,5 +1,5 @@
-# Round Flow
-
```admonish warning "Attention: Placeholder!"
This section is a placeholder, pending a design-doc being created by the related work-group
-```
\ No newline at end of file
+```
+
+# Round Flow
diff --git a/src/en/space-station-14/user-interface.md b/src/en/space-station-14/user-interface.md
index a573a6b3e..30f0eaa61 100644
--- a/src/en/space-station-14/user-interface.md
+++ b/src/en/space-station-14/user-interface.md
@@ -1,5 +1,5 @@
-# User Interface
-
```admonish warning "Attention: Placeholder!"
This section is a placeholder, pending a design-doc being created by the related work-group
-```
\ No newline at end of file
+```
+
+# User Interface
From 1ef37e88594c60705a6df9f7dbad81cb45872ea6 Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Sun, 2 Jun 2024 18:15:20 +0200
Subject: [PATCH 58/80] Add watchdog notification docs
---
src/en/server-hosting/setting-up-ss14-watchdog.md | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/en/server-hosting/setting-up-ss14-watchdog.md b/src/en/server-hosting/setting-up-ss14-watchdog.md
index 12826229c..f134c049a 100644
--- a/src/en/server-hosting/setting-up-ss14-watchdog.md
+++ b/src/en/server-hosting/setting-up-ss14-watchdog.md
@@ -89,6 +89,13 @@ See the relevant documentation for more details: https://docs.microsoft.com/en-u
Be sure to adjust BaseUrl accordingly!
+### Notifications
+You can now set a notification discord webhook to receive notifications whenever a server crashes, the integration is as simple as adding the following to your config.
+```yml
+Notification:
+ DiscordWebhook: "https://discord.com/api/webhooks/..."
+```
+
### Instances
Each instance is a separate game server, so the terms "instance" and "server" can be used semi-interchangably.
From 3f1e55370f9fd1710cdb503481ecae2a22ccfe03 Mon Sep 17 00:00:00 2001
From: Pieter-Jan Briers
Date: Sun, 2 Jun 2024 23:16:50 +0200
Subject: [PATCH 59/80] Link new Discord channel
---
src/en/general-development/contributing-translations.md | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/en/general-development/contributing-translations.md b/src/en/general-development/contributing-translations.md
index a4894c928..3950f65ac 100644
--- a/src/en/general-development/contributing-translations.md
+++ b/src/en/general-development/contributing-translations.md
@@ -14,3 +14,6 @@ As a new user, you only have the ability to submit suggestions. These need to be
If the language you want to translate to doesn't exist yet, also **just ask**. It requires a bit of manual work to set everything up for a new language.
+## Working Together
+
+Translation requires teamwork and coordination. If you wanna talk about translation stuff, the best place to do it is the `#translation` channel on our [Discord](https://discord.ss14.io).
\ No newline at end of file
From 5ebe05d2944470c2a1b84a26daac9bf5307b4c50 Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Tue, 4 Jun 2024 17:51:22 +0200
Subject: [PATCH 60/80] Explictly tell people ssl is required for ss14.admin
---
src/en/server-hosting/setting-up-ss14-admin.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/en/server-hosting/setting-up-ss14-admin.md b/src/en/server-hosting/setting-up-ss14-admin.md
index 6e6cfd423..85168829e 100644
--- a/src/en/server-hosting/setting-up-ss14-admin.md
+++ b/src/en/server-hosting/setting-up-ss14-admin.md
@@ -75,7 +75,7 @@ authServer: "https://auth.spacestation14.com"
```
```admonish warning
-I will STRONGLY recommend you put this behind a reverse proxy if you are not already with SSL.
+Due to how oauth works, you will require an SSL/HTTPS connection for the login to succeed. It does not matter if it's from a cert authority like Let's Encrypt or self signed. You just need it to be trusted so your browser will actually send over the necessary data.
```
## Authentication config
@@ -93,7 +93,7 @@ Your client secret will only be shown once, if you lose it make a new one.
```
## Finishing up
-Now try running `SS14.Admin` and you should have a working SS14.Admin instense after you visit it on your browser. If everything is looking right to you then all thats left is to set it to start in the background.
+Now try running `SS14.Admin` and you should have a working SS14.Admin instance after you visit it on your browser. If everything is looking right to you then all thats left is to set it to start in the background. To actually be able to login (as mentioned two warnings above) you will need to setup SSL on your domain usually with the help of a reverse proxy software. If you use caddy this is probably done for you. For nginx you can use something like [certbot](https://certbot.eff.org/instructions) to generate one with Let's Encrypt.
## Systemd Unit
From d20d3ca8628df8fc1c9c847b7d4c0b42891ccc47 Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Wed, 5 Jun 2024 20:54:42 +0200
Subject: [PATCH 61/80] OK now this should work
---
.github/labeler.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/.github/labeler.yml b/.github/labeler.yml
index d0b8f9671..fc27e6f78 100644
--- a/.github/labeler.yml
+++ b/.github/labeler.yml
@@ -12,5 +12,5 @@
"Design":
- changed-files:
- - any-glob-to-any-file: '**/proposals/**'
- - 'src/en/general-proposals/**'
+- 'src/*/space-station-14/*/proposals/**'
+- 'src/*/general-proposals/**'
From 6c973e5c052664378835edd7986567c9b233843e Mon Sep 17 00:00:00 2001
From: nikthechampiongr <32041239+nikthechampiongr@users.noreply.github.com>
Date: Wed, 5 Jun 2024 19:40:18 +0000
Subject: [PATCH 62/80] Admin minutes 6 (#232)
Add minutes for 2024-05-18 admin meeting.
This should have been done like a week or two ago but I forgor.
---
src/SUMMARY.md | 1 +
.../admin-meeting-2024-05-18.md | 266 ++++++++++++++++++
2 files changed, 267 insertions(+)
create mode 100644 src/en/admin-meetings/admin-meeting-2024-05-18.md
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index ec89ddad9..8fb29acf2 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -366,6 +366,7 @@ Admin Meetings
==============
----------------------
+- [2024-05-18](en/admin-meetings/admin-meeting-2024-05-18.md)
- [2024-04-27](en/admin-meetings/admin-meeting-2024-04-27.md)
- [2024-03-30](en/admin-meetings/admin-meeting-2024-03-30.md)
- [2024-03-16](en/admin-meetings/admin-meeting-2024-03-16.md)
diff --git a/src/en/admin-meetings/admin-meeting-2024-05-18.md b/src/en/admin-meetings/admin-meeting-2024-05-18.md
new file mode 100644
index 000000000..0ff47b823
--- /dev/null
+++ b/src/en/admin-meetings/admin-meeting-2024-05-18.md
@@ -0,0 +1,266 @@
+# Admin Meeting 2024-05-18
+
+## Agenda
+
+
+- Brief updates from last meeting
+- Discourse
+- Trialmin Discoursification
+- Trialmin Onboarding
+- Silicon Policy
+- Disclosed Ban Evasion and Alts
+- Review minutes
+
+## Topic Details
+
+
+
+### Brief updates from last meeting
+
+The last meeting's minutes are available at [link]
+
+#### Summary
+
+> - There's currently an internal discussion thread about the salamander whitelist
+> - I've been working on the rule rewrite, including metashield draft
+> - Discourse still real
+> -Chief_Engineer
+
+#### Meeting Goals
+
+1. Communicate updates related to items from the last meeting to admins attending the meeting.
+
+### Discourse
+
+#### Summary
+
+
+> Discourse is here. Has anyone noticed any issues, or have any concerns right now?
+>
+> What about suggestions?
+> -Chief_Engineer
+
+#### Meeting Goals
+
+
+1. Compile a list of issues that game admin noticed with Discourse
+2. Compile a list of concerns that game admins have with Discourse
+3. Compile a list of actionable suggestions that game admins have for improving Discourse
+
+### Trialmin Discoursification
+
+#### Summary
+
+
+> Can any trialmin processes be moved to Discourse? How should that move happen?
+>
+> The main limitations to keep in mind are:
+> - Discourse does not allow user level permissions on categories, only user group level
+> - People probably do not monitor Discourse as closely as they do Discord
+> - Discord relays can only filter by category and tag. Topic creation or all posts can be relayed to a channel. You cannot relay to a Discord thread or to a specific location per Discourse topic.
+>
+> Main goals are:
+> - Trialmins should not be able to see their internal threads even after becoming propermins
+> - There should be a clear place to go to say "there is a widespread issue with most/all current trialmins"
+> - There should be a clear place to go to s ay "there is an issue with this specific trialmin". This can be the same place as for multi trialmin issues, but a specific place per trialmin may be more ideal
+> - Mentors must be able to see at least the threads for their own trialmins
+>
+> Here's an idea I had:
+> A category is created that can only be seen by either propermins or trialmin mentors, I'm not sure which option is better. A "vault" subcategory is created that can only be seen by head admins. Internal threads for trialmins are created in the category, and then moved to the vault when the trialmin ends their trial. Discord thread is retained and is used either for widespread issues or as the team wide thread if propermins don't have access to the trialmin discourse topics. Having the subcategory be mentors only might be preferred. If two trialmins were involved in a situation, the incident might be described in both trialmins' threads. Having a mentor category instead of a propermin category would allow us to keep both from seeing the information by preventing either from being a mentor until both finish their trials rather than requiring us to do a synchronous promotion.
+> -Chief_Engineer
+
+#### Meeting Goals
+
+
+1. Collect any potential issues or concerns related to moving trialmin stuff to the forums
+2. Identify possible ways to improve the trialmin process by moving parts to discourse
+
+### Trialmin Onboarding
+
+#### Summary
+
+
+> Is there anything that's currently outdated or could be improved with trialmin onboarding?
+> -Chief_Engineer
+
+#### Meeting Goals
+
+1. Identify any specific issues with the trialmin onboarding process
+
+### Silicon Policy
+
+#### Summary
+
+
+> Borgs and their laws are flawed. They're meant to be that way but we all know they've been a bit of a headache to deal with both for admins and players. They should be flawed, but not in such a way that loopholes can be used to break server rules and/or ruin someone's round because technically they can.
+> -Kezu
+
+#### Meeting Goals
+
+Compile admin team opinions on the following questions:
+1. What should be the restrictions/limitations of borgs?
+2. What loopholes should be closed?
+
+### Disclosed Ban Evasion and Alts
+
+#### Summary
+
+
+> [link]
+>
+> Want to reaffirm our position surrounding ban evasion using this forum post as an example
+>
+> 1) A user simply stating they have/have had used an alt account does not discredit their attempt to ban evade.
+> - The above mentioned ban appeal was made after a ban evasion attempt was made, likely admitting to the alt in hopes that it would not result in a voucher upgrade.
+>
+> 2) A user that elects to admit they have an alt should have the alt banned immediately via GUID due to it being against our rules
+> - This point specifcly is shakey as technically in our rules, even having an alt account is grounds for immediate appeal only bans on all of them.
+> -TurboTracker
+
+> I agree with the idea that disclosing an alt or ban evasion does not exonerate a player, but I don't think the reason for disclosure can or should be read into too much. The appeal wizard currently asks players to list their alternate accounts. If we are drawing a negative inference from a player truthfully answering that question, we wouldn't be able to also draw a negative inference from them lying by listing no alts, even though it seems to make more sense to draw the negative inference when they lie rather than when they are honest.
+>
+> Multikey disclosed via appeals I think needs to be handled case by case. Alternate accounts should always be account banned, but if, for example, they never connected to WizDen, or only ever connected once years ago, then there's probably no need to treat that like multikey.
+>
+> [WITHHELD]
+> -Chief_Engineer
+
+#### Meeting Goals
+
+
+Collect admin opinions on the following questions to act as guidelines until the completion of the policy rewrite, and that can be considered while rewriting policies and guidelines:
+1. How should a player disclosing an alternate account used in ban evasion, or the ban evasion attempt itself, affect the player's appeal? Should failure to disclose have any effect?
+2. How should multikey be handled when it is disclosed through an appeal? Does it matter if the ban is temporary or indefinite?
+
+### Review minutes
+
+#### Summary
+
+> The meeting minutes provide a record of the meeting for those who could not attend, and they are used to action decisions made in the meeting. For these reasons, it is important that they accurately represent what actually happened in the meeting.
+> -Chief_Engineer
+
+#### Meeting Goals
+
+1. Ensure that nothing important is missing or misrepresented in the minutes.
+2. Attempt to ensure that all topics have met their meeting goals. This can be done by ensuring that each meeting goal is directly addressed by the conclusion of the topic's minutes.
+3. Attempt to ensure that all conclusions fit into one of the following categories:
+ 1. Indicate that a meeting goal was completed.
+ 2. Are something actionable, meaning that they not only call for an action, but that action is specific enough that it does not require answering questions like "what exactly needs to be done?" or "how can this be done?"
+ 3. Clearly indicate that the meeting goals for the topic were not met. Examples: the discussion was tabled, the admin team did not reach a conclusion, the admin team was not able to make the conclusion actionable.
+
+```admonish info
+
+## Attendees
+
+
+- Skarlet - Headmin, Mediator
+- nikthechampiongr - Propermin, Minutes Editor
+- Crazybrain - Propermin
+- Geekyhobo - Propermin
+- Kezu - Propermin
+- ajexrose - Propermin
+- Violet - Propermin
+- Kayek - Propermin
+- Sphiral - Propermin
+- TurboTracker - Propermin
+- Repo - Propermin
+- TheChudster - Propermin
+- ryan_strudfelt - Propermin
+- CptJeanLuc - Propermin
+- Stealth16 - Propermin
+- Lunacomets - Propermin
+- Sammy - Trialmin
+- GalaxyCad - Trialmin
+```
+
+## Minutes
+
+### Brief Update
+
+- Editor's note: From these minutes onward I will not actually be writing anything in this section unless something additional is said and is relevant. The topic description alreay has everything.
+
+
+### Discourse
+
+- It seems attached videos do not work.
+- Onboarding admins on discourse has been troublesome with admins often getting confused with some obscure features.
+- TODO dates are not formatted the same as hedgedoc.
+- ~~There is literally nothing else wrong with discourse~~ Any further issues have been discussed in [this thread](https://discord.com/channels/310555209753690112/1233561013945761836)
+
+```admonish info "Conclusion"
+
+
+
+Issues brought up will be looked at by CE. Further issues should be redirected to [this thread](https://discord.com/channels/310555209753690112/1233561013945761836).
+
+```
+
+### Trialmin Discoursification
+
+- With CE's proposal, all mentors will be able to view all the trialmin threads since we cannot set individual user permissions.
+ - We could technically abuse user groups to emulate individual permissions, however this would be hell to manage.
+ - We generally wish to keep trialmin discussions by mentors sealed after that trial period is over. This is mainly because of how both mentors, and newly promoted propermins alike react to old statements.
+- Admins are still not used to discourse, although putting the trialmin process on discourse will allow new trialmins to quickly learn and use discourse more effectively.
+
+```admonish info "Conclusion"
+
+
+
+
+We will not be moving all of the trialmin process to discourse at this time. We will however utilize discourse's features to make onboarding smoother which we couldn't do with just discord and invision.
+
+```
+
+### Trialmin Onboarding
+
+- We can utilize discourse features to make onboarding smoother for trialmins. For example:
+ - By making our onboarding docs more interactive. For example we can allow for trialmins to mark their progress.
+ - Allow for trialmins to ask questions easier without having to post it in admin general for every admin to see, or to have to specifically approach a mentor in dms.
+- Docs are outdated for policy regarding trialmins processing appeals and events.
+- Onboarding docs generally could do with a small rewrite.
+
+```admonish info "Conclusion"
+
+
+
+Trialmin onboarding docs will be cleaned up and discourse will have a greater role in onboarding.
+
+```
+
+
+### Silicon Policy
+
+- Both players and admins sometimes seem to think that borg laws and the rules around them override other rules such as "Don't be a dick", or our escalation rules. We should clarify that borgs are still fully bound by the rules, unless it's explicitly stated that they are not by the rules. A clarification will be published on this topic.
+- We could also request that the laws be changed but it's likely any changes would also be rules-lawyered, or be too restrictive.
+
+```admonish info "Conclusion"
+
+
+
+Currently the most prevalent issue is borg players assuming their laws override station rules. This topic will be further discussed in a discourse topic.
+
+```
+
+### Disclosed Ban Evasion and Alts
+
+- [WITHHELD]
+- When an alt is disclosed, regardless of any other circumstances that alt should be gamebanned so that it cannot be used. This should not be applied to the main account.
+ - We need a response template for this.
+- We should not draw adverse inferences against appellants for propery disclosing alt accounts.
+ - This means we should not immediately apply a voucher ban for alting if they disclose they have another account without proof of evasion.
+
+```admonish info "Conclusion"
+
+
+We will define that disclosed alt accounts will immediately be banned without affecting the main account. Disclosure is not grounds for an immediately voucher ban. [WITHHELD]
+```
+
+### Discussion outside Agenda Items
+
+- All topics except for ones that are literally 1 point long or empty will have a conclusion instead of being at the discretion of the editor. Editor's note: :despair: (This used to be an image in the original minutes however I cannot do it on mdbook without adding it to the repo which I don't wish to do.)
+
+## Overall Conclusion
+
+
+We will be utilizing discourse more for trialmin onboarding, however discussion and reviews for trialmins will be kept in discord. Borg rules will be clarified so that borgs cannot claim that their laws allow them to violate other rules. We now have a clear policy with how to deal with disclosed ban accounts: The account will be banned without any further action on the main account.
+
+🦀
From 56167f7108f9cc0d967f3a1220cdfb49e38fd5ab Mon Sep 17 00:00:00 2001
From: Chief-Engineer <119664036+Chief-Engineer@users.noreply.github.com>
Date: Thu, 6 Jun 2024 04:04:03 -0500
Subject: [PATCH 63/80] banning policy update to pair with rule rewrite (#229)
---
.../admin/wizards-den-banning-policy.md | 171 +++++++++++-------
1 file changed, 102 insertions(+), 69 deletions(-)
diff --git a/src/en/community/admin/wizards-den-banning-policy.md b/src/en/community/admin/wizards-den-banning-policy.md
index 9b2ff9666..d3e0e876b 100644
--- a/src/en/community/admin/wizards-den-banning-policy.md
+++ b/src/en/community/admin/wizards-den-banning-policy.md
@@ -5,12 +5,12 @@ This is the ban policy for Wizard's Den servers. It applies only to our first-pa
```
# Definitions
-- **Indefinite:** Refers to a ban with no defined end time. This type of ban generally requires a successful appeal for it to be removed. Indefinite bans which have no extra requirements may be called *appeal bans*.
-- **Voucher:** Confirmation from a member of the admin team of another well known SS14 or SS13 server that you have played on that server for a significant amount of time without any recent major issues. A voucher is required when appealing a *voucher ban*.
+- **Indefinite:** Refers to a ban with no defined end time. This type of ban generally requires a successful appeal for it to be removed. Indefinite bans which have no extra requirements are sometimes called *appeal bans*.
+- **Voucher:** Confirmation from the admin team of another well known SS14 or SS13 server that you have played on that server for a significant amount of time without any recent major issues. A voucher is required when appealing a *voucher ban*.
- **Voucher ban:** A ban which requires a *voucher* to appeal. These bans can also typically only be appealed after at least 6 months from the date of the ban. They are often used as an alternative to a *permanent ban* that allows players to return if they can demonstrate an ability to follow a server's rules.
- **Warning:** A warning is a clear communication from an admin that some behavior is not acceptable. Warnings should always be paired with an account note making note of the warning and behavior.
- **Permanent ban:** A ban which cannot be appealed. These bans are sometimes called *perma bans*.
-- **Game ban:** A ban from the servers. A player who is *game banned* cannot connect to the servers during the ban.
+- **Game ban:** A ban from the servers. A player who is *game banned* cannot connect to the servers during the ban. These bans are sometimes called *server bans*.
- **Role ban:** A ban from a specific role or roles.
- **Ban evasion:** Attempting to circumvent an active ban.
@@ -39,7 +39,7 @@ Administrators who place bans outside of the guidelines are required to be able
```
```admonish info
-Consulting the admin team via Discord, or multiple (2 or more) other game admins in-game through admin chat or ahelp does not result in those bans being presumed to be of an appropriate length, but is sufficient justification for straying from the guidelines.
+Consulting the admin team via Discord, or consulting multiple (2 or more) other game admins in-game through admin chat or ahelp does not result in those bans being presumed to be of an appropriate length, but is sufficient justification for straying from the guidelines.
```
```admonish info
@@ -65,7 +65,11 @@ In most cases, ban reasons should clearly communicate the reason for the ban to
Alternate account bans should typically be in the form `Alt of OriginalUsername` or `AltUsername alt of OriginalUsername`.
-Bans of additional non-username information should typically include another ban on the GUID of the targeted player and should have a reason with just the account username. The earliest placed ban's reason will appear for the player when trying to connect.
+Bans of additional non-username information should typically include the GUID of the targeted player as a ban detail and should have a reason with just the account username. The earliest placed ban's reason will appear for the player when trying to connect.
+
+## Dewhitelisting
+
+Game admins may dewhitelist a player at their discretion in any case where an issue would likely have prevented whitelisting. Game admins are encouraged to pair bans which are either for a second offense of an issue or which are greater than 3 days with dewhitelisting.
## Offense Table
@@ -92,54 +96,54 @@ Rule violations not in the offense table can still have bans applied, but have n
| Grouping Category | Offense | First Offense | Second Offense | Third Offense | Fourth Offense |
|-------------------|------------------------------------------------------------------------------------------------------------|----------------|--------------------------------------------------------------------------------------------------------------------------|---------------|----------------|
-| Escalation | [Over escalation](https://wiki.spacestation14.io/wiki/Server_Rules#Follow_escalation_rules,_don't_make_Cargonia)[^eachVictim] | W | 12hr GB | 3d GB | **7d** - 7.5d GB |
-| Escalation | [RDM](https://wiki.spacestation14.io/wiki/Server_Rules#Follow_escalation_rules,_don't_make_Cargonia)[^eachVictim] | 12hr GB | 3d GB | **7d** - 7.5d GB | |
-| Escalation | [Over escalation or RDM that is a secondary result of station sabotage](https://wiki.spacestation14.io/wiki/Server_Rules#Follow_escalation_rules,_don't_make_Cargonia)[^stationSabotageRDM] | 12hr GB | 3d GB | **7d** - 7.5d GB | |
-| Self-antag | [Self-antag](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_intentionally_make_everything_worse_[Self-Antagonism])[^excludingEscalationIssues] | W - 12hr GB | 12hr - 3d GB | **7d** - 7.5d GB | |
-| Self-antag | [Station sabotage](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_intentionally_make_everything_worse_[Self-Antagonism])[^stationSabotage] | W - 3d GB | 12hr - 7d GB | 14d - 15d GB | |
-| Self-antag | [Cults/riots/revolutions](https://wiki.spacestation14.io/wiki/Server_Rules#Follow_escalation_rules,_don't_make_Cargonia) | **12hr** - 3d GB | 12hr - **3d** - 7d GB | **7d** - 7.5d GB | |
-| Self-antag | [Cooperating with known antags](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_intentionally_make_everything_worse_[Self-Antagonism]) | 12hr GB | 3d GB | **7d** - 7.5d GB | |
-| Non-grouping | [Harassing staff through the game](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_abuse/ignore_the_admin-help_relay) | Indef GB | | | |
-| Non-grouping | [Slurs, excluding "retard" and variants](https://wiki.spacestation14.io/wiki/Server_Rules#No_hate_speech,_slurs,_bigotry,_racism,_specism,_sexism,_etc.) | Indef GB | | | |
-| Non-grouping | ["Retard" and variants](https://wiki.spacestation14.io/wiki/Server_Rules#No_hate_speech,_slurs,_bigotry,_racism,_specism,_sexism,_etc.) | W | 1d - 3d GB | Indef GB | |
-| Non-grouping | [Bigotry/discrimination](https://wiki.spacestation14.io/wiki/Server_Rules#No_hate_speech,_slurs,_bigotry,_racism,_specism,_sexism,_etc.)[^discrimination] | Indef GB | | | |
-| Non-grouping | [ERP](https://wiki.spacestation14.io/wiki/Server_Rules#No_erotic_roleplay_(ERP)_or_sexual_content/themes) | Indef GB | | | |
-| Non-grouping | [Sexual content](https://wiki.spacestation14.io/wiki/Server_Rules#No_erotic_roleplay_(ERP)_or_sexual_content/themes) | W - 3d GB | 7d GB | Indef GB | |
-| Non-grouping | [Ban Evasion](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_attempt_to_evade_bans) | Voucher Ban | If after an accepted voucher ban, permanent ban.
Otherwise, extend voucher ban to 6 months from evasion attempt. | | |
-| Language | [Non-english chat](https://wiki.spacestation14.io/wiki/Server_Rules#English_only) | W | W - 12hr GB | 3d GB | **7d** - 7.5d GB |
-| Language | [Solely non-english chat](https://wiki.spacestation14.io/wiki/Server_Rules#English_only) | W | Indef GB | | |
-| Non-grouping | [Bugs/exploits](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_use_exploits_or_crash_the_server) | **W** - 7d GB | 12hr - 7d GB | 3d - 15d GB | 7d - 15d GB |
-| Non-grouping | [Use of macros](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_use_exploits_or_crash_the_server) | W | W - 12hr GB | 3d GB | **7d** - 7.5d GB |
-| Non-grouping | [Multi-keying](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_use_multiple_SS14_accounts_[Multi-keying]) | W - **Indef** GB | Indef GB | | |
-| Non-grouping | [Ahelp misuse in bad faith](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_abuse/ignore_the_admin-help_relay)[^badFaith] | **W** - 12hr GB | 12hr - 3d GB | **7d** - 7.5d GB | |
-| Non-grouping | [Bad character name](https://wiki.spacestation14.io/wiki/Server_Rules#Act_like_a_human_being)[^requiresIntent] | **W** - 12hr GB | **12hr** - 3d GB | **7d** - 7.5d GB | |
-| Metacomms | [Metacommunications](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_use_external_means_to_communicate_with_other_players_[Metacomming]) | Indef GB | | | |
-| Immersion | [Text speak](https://wiki.spacestation14.io/wiki/Server_Rules#Act_like_a_human_being) | W | W | **W** - 12hr GB | W - 12hr GB |
-| Immersion | [OOC terms IC](https://wiki.spacestation14.io/wiki/Server_Rules#Act_like_a_human_being)[^teachingException] | W | **W** - 12hr GB | **12hr** - 3d GB | 3d - 7.5d GB |
-| Immersion | [Bypassing chat restrictions](https://wiki.spacestation14.io/wiki/Server_Rules#Act_like_a_human_being) | W | W - **4hr** - 12hr GB | 12hr - 3d GB | 3d - 7.5d GB |
-| Griefing | [Damage/disruption to arrivals/arrivals shuttle](https://wiki.spacestation14.io/wiki/Server_Rules#Don't_be_a_dick) | 12hr - 3d GB | 3d - 7d GB | 7d - 15d GB | |
-| Griefing | [Harassing a player/role/department outside of reasonable conflicts](https://wiki.spacestation14.io/wiki/Server_Rules#Don't_be_a_dick) | W - 12hr GB | 12hr - 3d GB | **7d** - 7.5d GB | |
-| Griefing | [Round stalling](https://wiki.spacestation14.io/wiki/Server_Rules#Don't_be_a_dick) | **W** - 12hr GB | **12hr** - 3d GB | 3d - 7d GB | **7d** - 7.5d GB |
-| Griefing | [Early massive station sabotage](https://wiki.spacestation14.io/wiki/Server_Rules#Antagonist-Specific_Rules:_Traitor)[^antagOnly] | W - 12hr GB | 12hr - 3d GB | **7d** - 7.5d GB | |
-| Griefing | [Antagonist team sabotage](https://wiki.spacestation14.io/wiki/Server_Rules#Antagonist-Specific_Rules:_Nuclear_Operatives)[^antagOnly] | 12hr - 3d GB | 3d - Indef GB | 7d - Indef GB | |
-| Griefing | [Grief as minor antag](https://wiki.spacestation14.io/wiki/Server_Rules#Antagonist-Specific_Rules:_Minor_Antagonists)[^antagOnly] | **W** - 12hr GB | 12hr - 3d GB | 3d - 7d GB | 7d - 15d GB |
-| Griefing | [Abandoning a role](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_suicide_out_of_or_waste_important_roles,_including_antagonist_roles)[^abandoningRole] | W - 3d RB | 3d - 7d RB | Indef RB | |
-| Griefing | [Antag rolling](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_suicide_out_of_or_waste_important_roles,_including_antagonist_roles) | 12hr - 3d GB | 3d - 7d GB | **7d** - 7.5d GB | |
-| Griefing | [Friendly antag](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_suicide_out_of_or_waste_important_roles,_including_antagonist_roles)[^antagOnly] | **W** - 12hr GB | 12hr - 3d GB | **7d** - 7.5d GB | |
-| Metagaming | [Using info from death](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_use_outside_information_to_gain_an_advantage_[Metagaming])[^infoFromDeath] | W - 12hr GB | 12hr - 3d GB | 3d - 7.5d GB | |
-| Metagaming | [Using info from past life](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_use_outside_information_to_gain_an_advantage_[Metagaming]) | 12hr - 48hr GB | 3d GB | **7d** - 7.5d GB | |
-| Metagaming | [Metagaming round type](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_use_outside_information_to_gain_an_advantage_[Metagaming]) | W - 12hr GB | 12hr - 3d GB | 3d - 7.5d GB | |
-| Metagaming | [Preemptive PDA swapping](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_use_outside_information_to_gain_an_advantage_[Metagaming]) | W | 3d - 7d RB | 7d - 15d RB | |
-| Metagaming | [Preparing items not needed IC](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_pre-emptively_rush_for_weapons_and_equipment_[Powergaming]) | W | W - 12hr GB | 12hr - 3d GB | 3d - 7.5d GB |
-| Metagaming | [IC in OOC](https://wiki.spacestation14.io/wiki/Server_Rules#Do_not_use_outside_information_to_gain_an_advantage_[Metagaming]) | W | W - 12hr GB | 3d GB | **7d** - 7.5d GB |
-| Competence | [Unreasonable incompetence in role](https://wiki.spacestation14.io/wiki/Server_Rules#Department_Specific_Behavior_Issues) | W - **3d** - 7d RB | 7d - 15d RB | Indef RB | |
-| Competence | [Unreasonable failure of security/command to maintain order](https://wiki.spacestation14.io/wiki/Server_Rules#Command_&_Security_are_held_to_a_higher_standard) | 3d - 7d RB | 7d - 15d RB | Indef RB | |
-| Competence | [Abuse of a position of authority](https://wiki.spacestation14.io/wiki/Server_Rules#Command_&_Security_are_held_to_a_higher_standard) | 3d - 7d RB | 7d - 15d RB | Indef RB | |
-| Competence | [Taking actions a reasonable person would view as to be to the detriment of the station as security/command](https://wiki.spacestation14.io/wiki/Server_Rules#Command_&_Security_are_held_to_a_higher_standard) | 3d - 7d RB | 7d - 15d RB | Indef RB | |
-| Competence | [Failure of security to give medical aid to prisoners](https://wiki.spacestation14.io/wiki/Server_Rules#Command_&_Security_engagement_rules) | W - **3d** - 7d RB | 7d - 15d RB | Indef RB | |
-| Competence | [Unauthorized execution](https://wiki.spacestation14.io/wiki/Server_Rules#Command_&_Security_will_be_reasonable_with_punishments)[^stackEscalation][^applyToChain] | W | 3d - 7.5d RB | Indef RB | |
-| AI | [Minor failure to follow silicon laws](https://wiki.spacestation14.io/wiki/Server_Rules#Cyborg,_AI,_and_Silicon_Rules) | W | W - 3d RB | 3d - 7.5d RB | Indef RB |
-| AI | [Major failure to follow silicon laws](https://wiki.spacestation14.io/wiki/Server_Rules#Cyborg,_AI,_and_Silicon_Rules) | W - 3d RB | 3d - 7.5d RB | Indef RB | |
+| Non-grouping | Harassing staff through the game | Indef GB | | | |
+| Non-grouping | Slurs, excluding "retard" and variants | Indef GB | | | |
+| Non-grouping | "Retard" and variants | W | 1d - 3d GB | Indef GB | |
+| Non-grouping | Bigotry/discrimination[^discrimination] | Indef GB | | | |
+| Non-grouping | ERP | Indef GB | | | |
+| Non-grouping | Sexual content | W - 3d GB | 7d GB | Indef GB | |
+| Non-grouping | Metacommunications | Indef GB | | | |
+| Non-grouping | Ban Evasion | Voucher Ban | If after an accepted voucher ban, permanent ban.
Otherwise, extend voucher ban to 6 months from evasion attempt. | | |
+| Language | Non-english chat | W | W - 12hr GB | 3d GB | **7d** - 7.5d GB |
+| Language | Solely non-english chat | W | Indef GB | | |
+| Exploits | Bugs/exploits | **W** - 7d GB | 12hr - 7d GB | 3d - 15d GB | 7d - 15d GB |
+| Exploits | Use of macros | W | W - 12hr GB | 3d GB | **7d** - 7.5d GB |
+| Non-grouping | Multi-keying | W - **Indef** GB | Indef GB | | |
+| Non-grouping | Ahelp misuse in bad faith[^badFaith] | **W** - 12hr GB | 12hr - 3d GB | **7d** - 7.5d GB | |
+| Non-grouping | Threats to ahelp | **W** - 12hr GB | 12hr - 3d GB | **7d** - 7.5d GB | |
+| Non-grouping | Under 16 | Indef GB | | | |
+| Non-grouping | Bad character name[^requiresIntent] | **W** - 12hr GB | **12hr** - 3d GB | **7d** - 7.5d GB | |
+| Metagaming | IC in OOC[^positiveException] | W | W - 12hr GB | 3d GB | **7d** - 7.5d GB |
+| AI Laws | Major failure to follow silicon laws | W - 5d RB | 3d - 7.5d RB | Indef RB | |
+| AI Laws | Minor failure to follow silicon laws | W | W - 5d RB | 3d - 7.5d RB | Indef RB |
+| Familiars | Familiar griefing master | 12hr GB | 3d GB | **7d** - 7.5d GB | |
+| Familiars | Familiar unreasonable failure to obey orders | W | 12hr GB | 3d GB | **7d** - 7.5d GB |
+| Immersion | Text speak | W | W | **W** - 12hr GB | W - 12hr GB |
+| Immersion | OOC terms IC[^teachingException] | W | **W** - 12hr GB | **12hr** - 3d GB | 3d - 7.5d GB |
+| Immersion | Bypassing chat restrictions | W | W - **4hr** - 12hr GB | 12hr - 3d GB | 3d - 7.5d GB |
+| Metagaming | Using info from death[^infoFromDeath] | W - 12hr GB | 12hr - 3d GB | 3d - 7.5d GB | |
+| Metagaming | Using info from past life | 12hr - 48hr GB | 3d GB | **7d** - 7.5d GB | |
+| Metagaming | Metagaming round type | W - 12hr GB | 12hr - 3d GB | 3d - 7.5d GB | |
+| Griefing | Damage/disruption to arrivals/arrivals shuttle | 12hr - 3d GB | 3d - 7d GB | 7d - 15d GB | |
+| Self-antag | Self-antag[^excludingEscalationIssues] | W - 12hr GB | 12hr - 3d GB | **7d** - 7.5d GB | |
+| Self-antag | Station sabotage[^stationSabotage] | W - 3d GB | 12hr - 7d GB | 14d - 15d GB | |
+| Self-antag | Cults/riots/revolutions | **12hr** - 3d GB | 12hr - **3d** - 7d GB | **7d** - 7.5d GB | |
+| Self-antag | Cooperating with known antags | 12hr GB | 3d GB | **7d** - 7.5d GB | |
+| Griefing | Round stalling | **W** - 12hr GB | **12hr** - 3d GB | 3d - 7d GB | **7d** - 7.5d GB |
+| Griefing | Friendly antag[^antagOnly] | **W** - 12hr GB | 12hr - 3d GB | **7d** - 7.5d GB | |
+| Griefing | Antagonist team sabotage[^antagOnly] | 12hr - 3d GB | 3d - Indef GB | 7d - Indef GB | |
+| Griefing | Early massive station sabotage[^antagOnly] | **W** - 12hr GB | 12hr - 3d GB | **7d** - 7.5d GB | |
+| Griefing | Unreasonable failure to follow an order from a team leader | W - 5d RB | 3d - 7d RB | Indef RB | |
+| Griefing | Harassing a player/role/department with no IC conflict | W - 12hr GB | 12hr - 3d GB | **7d** - 7.5d GB | |
+| Escalation | Over escalation[^eachVictim] | W | 12hr GB | 3d GB | **7d** - 7.5d GB |
+| Escalation | RDM[^eachVictim] | 12hr GB | 3d GB | **7d** - 7.5d GB | |
+| Escalation | Over escalation or RDM that is a secondary result of station sabotage[^stationSabotageRDM] | 12hr GB | 3d GB | **7d** - 7.5d GB | |
+| Griefing | Abandoning a role[^abandoningRole] | W - 5d RB | 3d - 7d RB | Indef RB | |
+| Griefing | Antag rolling | 12hr - 3d GB | 3d - 7d GB | **7d** - 7.5d GB | |
+| Competence | Unreasonable incompetence in role | W - **3d** - 7d RB | 7d - 15d RB | Indef RB | |
+| Competence | Abuse of a position of authority | 3d - 7d RB | 7d - 15d RB | Indef RB | |
+| Competence | Taking actions a reasonable person would view as to be to the detriment of the station as security/command | 3d - 7d RB | 7d - 15d RB | Indef RB | |
+| Competence | Unreasonable failure of security/command to follow space law | W - **3d** - 7d RB | 7d - 15d RB | Indef RB | |
[^eachVictim]: Guideline is multiplied by the number of victims.
@@ -153,13 +157,13 @@ Rule violations not in the offense table can still have bans applied, but have n
[^badFaith]: To qualify as bad faith, there should be no *reasonable* way that something is being done with good intentions. It is not required for the person to *actually* be acting in bad faith, only that it is *unreasonable* for them to think that they are.
-[^antagOnly]: Only applies to antagonists.
+[^antagOnly]: Only applies to antagonists and free agents.
[^stackEscalation]: Should be combined with an escalation offense from the perspective of the offender. Typically RDM if an execution occurs for no reason, or over escalation if there is a poor reason.
[^teachingException]: Use of admin discretion to not enact penalties is highly recommended in cases where the offending player only commits an offense after attempting and failing to teach a new player appropriately.
-[^applyToChain]: The offense may be applied to anyone in the chain of those who requested or approved the execution up to the executioner.
+[^positiveException]: Use of admin discretion to not enact penalties is highly recommended in cases where the offending player is not negatively impacting players, and is attempting to ensure players have a positive experience. For example, using LOOC to get permission to perform an IC act which would be allowed even without that permission.
[^infoFromDeath]: This includes any information that a character should have not known from the same "life". Depending on server rules, this may include information like the information leading to your death. A "life" ends when a player takes a different role, like a ghost role. For the purposes of banning guidelines, a "life" does not end on cloning.
@@ -167,7 +171,7 @@ Rule violations not in the offense table can still have bans applied, but have n
[^requiresIntent]: Offenses where the admin does not believe a violation to have been intentional may be reduced to a warning and do not need to be considered a past offense when evaluating guidelines for future offenses.
-## Modifiers Table
+## Modifiers Tables
```admonish info
> Modifiers can be applied to each offense that meets their conditions. They are typically in the form of multipliers.
@@ -183,23 +187,48 @@ An offense which lists W - 12h GB as a suggestion that is affected by a 2x multi
--------------------
+### Mitigating: Required
+
+```admonish info
+These mitigating modifiers must be applied if they are applicable.
+```
+
| Modifier | Modification |
|----------|--------------|
-| Metagrudging | 2x multiplier if the offense is the result of metagrudging by the offender. |
-| Repeat game bans | A multiplier equal to 1 plus the number of game bans in the last 6 months which resulted from offenses from other grouping categories. This multiplier can only apply to game ban suggestions, not role ban suggestions. |
-| Prior indefinite ban | Up to 7d can be added to the total game ban length if the player has had a prior indefinite ban in the last 6 months. Excluding bans used only for contact and ones where they were found to be not at fault. |
-| Round removal | 2x multiplier for any offense which results in someone being permanently removed from a round, including an attempt to do so and actions likely to result in permanent round removal. |
-| Ban request/demand | Any player who demands or requests a ban can be banned indefinitely. |
-| Lying in ahelp | 24h + 1-3x multiplier if the offender maliciously lies in the ahelp. You should be certain that they have lied. The multiplier may be applied after the 24h addition is made. |
-| Role specific | Any issue that is likely to be prevented by a role ban should include a role ban if a game ban is applied. The role ban can be applied in addition to or as an alternative to the suggested game ban. Game ban suggestions can be converted to role ban suggestion times by doubling the time. |
-| Command/Security | 1-2x multiplier if the offender is in command or security |
-| Intentional rule breaking | 2-3x multiplier. Includes any rule breaking where the player intentionally breaks a rule knowing they are breaking a rule, knowing they will get banned, or claims to not care if they get banned. Any reasonably clear rule violation can be presumed to be intentional if the player was told to read the rules in the last 12 hours. |
-| New player | Anything from a warning to the maximum suggested ban can be given to a player new to the game if they are told to read the rules, if they have not been previously told to do so, and if the minimum suggestion is not an indefinite ban. |
| Valid Rule Clarification | No more than a warning should be given to a player that justifies the offense with a reasonably cited active rule clarification, even if it is not up to date with current rules. |
+| Self report | Reduce to warning. Applies to any offense where the player reports themselves as long as the offense was unlikely to be identified otherwise. |
+
+
+### Mitigating: Discretionary
+
+```admonish info
+These mitigating modifiers are applied at the discretion of the admin and may be partially applied. Admins are highly encouraged to consider applying these when they are relevant as they can significantly help to avoid bans which will be accepted on appeal.
+```
+
+| Modifier | Modification |
+|----------|--------------|
+| New player | If there is no prior warning for the same issue, and if the minimum suggestion is not an indefinite ban, reduce to warning at admin discretion and instruct to read the rules. |
| Caught before round effects | If there are no earlier similar issues, any issue caught before it affects the round and other players can be reduced to a warning at admin discretion. |
-| Self report | Reduce to warning. Applies to any offense where the player reports themselves and where the offense was unlikely to be identified otherwise. |
| Admin intervention | Any reduction, including to nothing, may be applied for any offense which is plausibly the result of admin intervention. |
+### Aggravating
+
+```admonish info
+Aggravating modifieres are applied at the discretion of the admin and may be partially applied.
+```
+
+| Modifier | Modification |
+|----------|--------------|
+| Repeat game bans | A multiplier equal to 1 plus the number of game bans in the last 6 months which resulted from offenses from other grouping categories. |
+| Metagrudging | **2x** multiplier if the offense is the result of metagrudging by the offender. |
+| Prior indefinite ban | **7d** can be added to the total game ban length if the player has had any prior indefinite ban in the last 6 months. Excluding bans used only for contact and ones where they were found to be not at fault. |
+| Round removal | **2x** multiplier for any offense which results in someone being permanently removed from a round, including an attempt to do so and actions likely to result in permanent round removal. |
+| Lying in ahelp | **24h + 3x** multiplier if the offender maliciously lies in the ahelp. You should be certain that they have lied. The multiplier is applied after the 24h addition is made. |
+| Command/Security | **2x** multiplier if the offender is in command or security |
+| Intentional rule breaking | **3x** multiplier. Includes any rule breaking where the player intentionally breaks a rule knowing they are breaking a rule, knowing they will get banned, or claims to not care if they get banned. Any reasonably clear rule violation can be presumed to be intentional if the player was told to read the rules in the last 12 hours. |
+| Role specific | Any issue that is likely to be prevented by a role ban should include a role ban if a game ban is applied. The role ban can be applied in addition to or as an alternative to the suggested game ban. Game ban suggestions can be converted to role ban suggestion times by doubling the time. |
+| Ban request/demand | Any player who demands or requests a ban can be banned indefinitely. |
+
## Grouping and Stacking
- When separate offenses occur, the suggested time should be determined by summing the suggestions for each separate offense.
@@ -217,6 +246,10 @@ The total time of a role ban may be rounded to the nearest available autofill.
## Examples
+```admonish info
+These examples may be outdated due to a banning policy update. Please point out any issues if you notice them.
+```
+
### AME Sabotage
A technical assistant sets the AME to 50. Their offenses are:
- Self antag
@@ -244,13 +277,13 @@ No modifiers apply. Only the prior RDM offense is relevant because it is the onl
# Appeals
-## Appeals of Mistaken Bans
+## Appeals of Incorrect Bans
Unless the ban was an upgrade resulting from an unsucessful appeal, if an appeal disputes the events which were used to justify the ban, the first appeal of a voucher or permanent ban may only be declined after it has been verified that it was appropriately placed.
## Appeal Hijacking
-If an appeal is currently being processed by someone, it is generally best to let them finish processing the it. Cases where it may be acceptable to "hijack" an appeal are:
+If an appeal is currently assigned to someone, it is generally best to let them finish processing the it. Cases where it may be acceptable to "hijack" an appeal are:
- the processor has not responded to the appeal recently,
- the processor has somehow indicated that they are not going to process the appeal, or
- a head game admin has told you that you can process the appeal.
From f9e13931079317720074b832938ffec49750b6c7 Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Thu, 6 Jun 2024 15:43:41 +0200
Subject: [PATCH 64/80] Update labeler.yml since I don't wanna deal with making
it robust anymore
I give up
---
.github/labeler.yml | 29 ++++++++++++++++++++++++++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/.github/labeler.yml b/.github/labeler.yml
index fc27e6f78..d331ab2d0 100644
--- a/.github/labeler.yml
+++ b/.github/labeler.yml
@@ -10,7 +10,30 @@
"Scripts":
- 'scripts/**'
+# I have tried making this robust (tm) using wildcards so many times but github docs for the labeler SUUUUCK. If you got time to figure it out please do it I give up.
+# Welcome to the mega labeler.
"Design":
-- changed-files:
-- 'src/*/space-station-14/*/proposals/**'
-- 'src/*/general-proposals/**'
+# General design
+- 'src/en/space-station-14/accessibility/proposals**'
+- 'src/en/space-station-14/admin-tools/proposals**'
+- 'src/en/space-station-14/art/proposals**'
+- 'src/en/space-station-14/character-species/proposals**'
+- 'src/en/space-station-14/combat/proposals**'
+- 'src/en/space-station-14/mapping/proposals**'
+- 'src/en/space-station-14/player-interaction/proposals**'
+- 'src/en/space-station-14/roleplay-lore/proposals**'
+- 'src/en/space-station-14/round-flow/proposals**'
+- 'src/en/space-station-14/user-interface/proposals**'
+
+# Department design
+- 'src/en/space-station-14/departments/atmos/proposals**'
+- 'src/en/space-station-14/departments/cargo-salvage/proposals**'
+- 'src/en/space-station-14/departments/command/proposals**'
+- 'src/en/space-station-14/departments/engineering/proposals**'
+- 'src/en/space-station-14/departments/medical/proposals**'
+- 'src/en/space-station-14/departments/science/proposals**'
+- 'src/en/space-station-14/departments/security/proposals**'
+- 'src/en/space-station-14/departments/service/proposals**'
+
+# General proposals
+- 'src/en/general-proposals/**'
From 1c4d1ae05fa3730ef8b75a6b42f140b951505d7b Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Thu, 6 Jun 2024 15:45:03 +0200
Subject: [PATCH 65/80] Update labeler.yml
---
.github/labeler.yml | 34 +++++++++++++++++-----------------
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/.github/labeler.yml b/.github/labeler.yml
index d331ab2d0..dc4ed4e7d 100644
--- a/.github/labeler.yml
+++ b/.github/labeler.yml
@@ -15,25 +15,25 @@
"Design":
# General design
- 'src/en/space-station-14/accessibility/proposals**'
-- 'src/en/space-station-14/admin-tools/proposals**'
-- 'src/en/space-station-14/art/proposals**'
-- 'src/en/space-station-14/character-species/proposals**'
-- 'src/en/space-station-14/combat/proposals**'
-- 'src/en/space-station-14/mapping/proposals**'
-- 'src/en/space-station-14/player-interaction/proposals**'
-- 'src/en/space-station-14/roleplay-lore/proposals**'
-- 'src/en/space-station-14/round-flow/proposals**'
-- 'src/en/space-station-14/user-interface/proposals**'
+- 'src/en/space-station-14/admin-tools/proposals/**'
+- 'src/en/space-station-14/art/proposals/**'
+- 'src/en/space-station-14/character-species/proposals/**'
+- 'src/en/space-station-14/combat/proposals/**'
+- 'src/en/space-station-14/mapping/proposals/**'
+- 'src/en/space-station-14/player-interaction/proposals/**'
+- 'src/en/space-station-14/roleplay-lore/proposals/**'
+- 'src/en/space-station-14/round-flow/proposals/**'
+- 'src/en/space-station-14/user-interface/proposals/**'
# Department design
-- 'src/en/space-station-14/departments/atmos/proposals**'
-- 'src/en/space-station-14/departments/cargo-salvage/proposals**'
-- 'src/en/space-station-14/departments/command/proposals**'
-- 'src/en/space-station-14/departments/engineering/proposals**'
-- 'src/en/space-station-14/departments/medical/proposals**'
-- 'src/en/space-station-14/departments/science/proposals**'
-- 'src/en/space-station-14/departments/security/proposals**'
-- 'src/en/space-station-14/departments/service/proposals**'
+- 'src/en/space-station-14/departments/atmos/proposals/**'
+- 'src/en/space-station-14/departments/cargo-salvage/proposals/**'
+- 'src/en/space-station-14/departments/command/proposals/**'
+- 'src/en/space-station-14/departments/engineering/proposals/**'
+- 'src/en/space-station-14/departments/medical/proposals/**'
+- 'src/en/space-station-14/departments/science/proposals/**'
+- 'src/en/space-station-14/departments/security/proposals/**'
+- 'src/en/space-station-14/departments/service/proposals/**'
# General proposals
- 'src/en/general-proposals/**'
From 5d08e2b2088809d03edc65b8fd41de716f1b047d Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Thu, 6 Jun 2024 15:45:48 +0200
Subject: [PATCH 66/80] Maybe i should stop directly commiting
Last time i swear
---
.github/labeler.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.github/labeler.yml b/.github/labeler.yml
index dc4ed4e7d..7c6022c03 100644
--- a/.github/labeler.yml
+++ b/.github/labeler.yml
@@ -14,7 +14,7 @@
# Welcome to the mega labeler.
"Design":
# General design
-- 'src/en/space-station-14/accessibility/proposals**'
+- 'src/en/space-station-14/accessibility/proposals/**'
- 'src/en/space-station-14/admin-tools/proposals/**'
- 'src/en/space-station-14/art/proposals/**'
- 'src/en/space-station-14/character-species/proposals/**'
From 4b5a2cdb9f90fd4791101e17c888c6ef985bc18c Mon Sep 17 00:00:00 2001
From: Thomas <87614336+Aeshus@users.noreply.github.com>
Date: Thu, 6 Jun 2024 16:10:33 -0500
Subject: [PATCH 67/80] Fix example (#236)
---
src/en/ss14-by-example/adding-a-simple-bikehorn.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/en/ss14-by-example/adding-a-simple-bikehorn.md b/src/en/ss14-by-example/adding-a-simple-bikehorn.md
index 77c5820e8..282415915 100644
--- a/src/en/ss14-by-example/adding-a-simple-bikehorn.md
+++ b/src/en/ss14-by-example/adding-a-simple-bikehorn.md
@@ -293,7 +293,7 @@ Also, we've added `[Dependency] private readonly SharedAudioSystem` to class. It
```csharp
private void OnUseInHand(Entity ent, ref UseInHandEvent args)
{
- _audio.PlayPvs(ent.Comp.Sound, uid);
+ _audio.PlayPvs(ent.Comp.Sound, ent.Owner);
}
```
@@ -305,7 +305,7 @@ In this case, we just pass it our `sound` field on our `PlaySoundOnUseComponent`
2. The source entity
-This is an optional argument that is used for positional audio. In our case, we want the sound to come from the horn, so we pass in the horn's Uid. If this arugment is not given, the sound is played globally and will be audible to all players.
+This is an optional argument that is used for positional audio. In our case, we want the sound to come from the horn, so we pass in the horn's Uid (which is the `Owner` property of the entity). If this arugment is not given, the sound is played globally and will be audible to all players.
If you compile the game and spawn our bike horn using the **F5** Entity Spawn Menu, you can try activating it in hand and--incredible! It plays the sound properly! Hopefully! If not, you might have messed something up in the YAML, or missed a method in the EntitySystem.
From 47e3cff3a30d1a23a6ee8e8bd30ac692aaed95ac Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Fri, 7 Jun 2024 00:32:13 +0300
Subject: [PATCH 68/80] Add more info the the watchdog setup (#234)
---
.../setting-up-ss14-watchdog.md | 60 ++++++++++++-------
1 file changed, 39 insertions(+), 21 deletions(-)
diff --git a/src/en/server-hosting/setting-up-ss14-watchdog.md b/src/en/server-hosting/setting-up-ss14-watchdog.md
index f134c049a..6f8849084 100644
--- a/src/en/server-hosting/setting-up-ss14-watchdog.md
+++ b/src/en/server-hosting/setting-up-ss14-watchdog.md
@@ -31,7 +31,7 @@ You need to have:
Both of these can be found at the [.NET 8 download page](https://dotnet.microsoft.com/en-us/download/dotnet/8.0).
-On Linux/MacOS use your favourite package manager (apt, dnf, pacman, brew etc) according to [Microsoft's installation instructions](https://learn.microsoft.com/en-us/dotnet/core/install/linux).
+On Linux use your favourite package manager (apt, dnf, pacman, brew etc) according to [Microsoft's installation instructions](https://learn.microsoft.com/en-us/dotnet/core/install/linux).
### 2. Build
@@ -48,12 +48,12 @@ cd SS14.Watchdog
dotnet publish -c Release -r linux-x64 --no-self-contained
```
-The contents of `SS14.Watchdog/bin/Release/net8.0/linux-x64/publish` can then be copied to some other place.
+The contents of `SS14.Watchdog/bin/Release/net8.0/linux-x64/publish` can then be copied to some other place. You will continue your work here.
### 3. Run
-Assuming you've followed the structure laid out above, you simply need to have a terminal at the "main directory", and run `bin/SS14.Watchdog`.
+Assuming you've followed the structure laid out above, you simply need to have a terminal in the folder you copied above, and run the `SS14.Watchdog` executable.
## Watchdog Configuration
@@ -85,7 +85,7 @@ In particular, this can be used to expose the Watchdog outside of localhost with
Urls: "http://*:5000"
```
-See the relevant documentation for more details: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/host/web-host?view=aspnetcore-8.0#server-urls
+See the relevant documentation for more details: [docs.microsoft.com](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/host/web-host?view=aspnetcore-8.0#server-urls)
Be sure to adjust BaseUrl accordingly!
@@ -149,14 +149,14 @@ Servers:
### Server Instance Folder
-The watchdog will automatically create a folder structure for each server instance. This is at `instances/`, e.g. `instances/wizards_den` / `instances/wizards_den_two`, relative to the current working directory when executing the watchdog.
+The watchdog will automatically create a folder structure for each server instance. This is at `instances/`, e.g. `instances/wizards_den` / `instances/wizards_den_two`, relative to the current working directory when executing the watchdog. In the example config above this would be `instances/example`
Each instance folder has the following files and folders:
* `binaries/`: Is used to store client binaries when using the "Local" update type, see below.
* `bin/`: Contains the actual extracted server binaries.
* `data/`: Stores server data like player preferences.
-* `config.toml`: Is the config file the server will load (the watchdog overrides the default location, `server_config.toml` next to the .exe, to avoid it getting deleted when the server resets).
+* `config.toml`: Is the config file the server will load (the watchdog overrides the default location, `server_config.toml` next to the .exe, to avoid it getting deleted when the server resets). You may have to create this file manually the first time.
* `data.json`: Contains watchdog information. If you changed the update type and are getting errors, delete this.
@@ -172,12 +172,16 @@ Firstly, the watchdog will only update when it is either explicitly notified to
Secondly, you may want to simply force a server to be restarted.
+Lastly, you may want to shutdown the server when the round ends. Example for maintenance.
+
These tasks can be achieved with the following commands:
`curl -v -X POST -u myInstance:ApiToken http://localhost:5000/instances/myInstance/restart`
`curl -v -X POST -u myInstance:ApiToken http://localhost:5000/instances/myInstance/update`
+`curl -v -X POST -u myInstance:ApiToken http://localhost:5000/instances/myInstance/stop`
+
## Update Types
### Manifest Update
@@ -186,22 +190,18 @@ These tasks can be achieved with the following commands:
The server still won't automatically be notified of updates, so see above for instructions.
```
-For vanilla servers, the "Manifest" update type and the standard manifest URL is enough.
+Manifest type is the method all Wizard's Den servers use and we recommend using. Manifest is required to be able to record [replays](../server-hosting/server-replay-recording.md)
```yml
Servers:
Instances:
example:
- # (skipped...)
+ # (This is an example, do NOT blindly copy paste this. Or you may end up with an unfinished configuration)
UpdateType: "Manifest"
Updates:
ManifestUrl: "https://central.spacestation14.io/builds/wizards/manifest.json"
```
-You will have to manually move files around and extract the server binaries.
-
-Note that you should not move around or attempt to delete the files of a running server.
-
### Git-based Updates
```admonish danger "Here be dragons!"
@@ -225,7 +225,7 @@ Also, you still need to write a Git hook or somesuch to ensure that the Watchdog
Servers:
Instances:
example:
- # (skipped...)
+ # (This is an example, do NOT blindly copy paste this. Or you may end up with an unfinished configuration)
UpdateType: "Git"
Updates:
# BaseUrl: The URL of the Git repository to watch.
@@ -246,7 +246,7 @@ This is an ancient method, but it should still work.
Servers:
Instances:
example:
- # (skipped...)
+ # (This is an example, do NOT blindly copy paste this. Or you may end up with an unfinished configuration)
UpdateType: "Jenkins"
Updates:
BaseUrl: "http://localhost:9938"
@@ -272,7 +272,7 @@ To configure this, use the following update configuration in your `appsettings.y
Servers:
Instances:
example:
- # (skipped...)
+ # (This is an example, do NOT blindly copy paste this. Or you may end up with an unfinished configuration)
UpdateType: "Dummy"
```
@@ -295,7 +295,7 @@ Start with configuring as so:
Servers:
Instances:
example:
- # (skipped...)
+ # (This is an example, do NOT blindly copy paste this. Or you may end up with an unfinished configuration)
UpdateType: "Dummy"
RunCommand: "./currentServer"
```
@@ -310,7 +310,7 @@ As such, three scripts, `switchTo`, `switchTo1` and `switchTo2`, are needed:
rm currentServer switch inactiveBin ; mkdir -p $1
ln -s $1/Robust.Server currentServer ; ln -s $2 switch ; ln -s $3 inactiveBin
echo Switching to $1
-curl -v -X POST -u myInstance:spooky http://localhost:5000/instances/myInstance/update
+curl -v -X POST -u myInstance:ApiToken http://localhost:5000/instances/myInstance/update
```
`switchTo1`:
@@ -333,7 +333,7 @@ Before clearing and extracting a new server build to `inactiveBin`, be sure to m
### DIY Manifest Server
-This is a quick script useful in setting up a DIY server for the Manifest update type described in the "For Vanilla Servers" section.
+This is a quick script useful in setting up a DIY server for the Manifest update type described in the manifest section.
It assumes you have some arbitrary static HTTP server, and you just need a script to output the JSON with an updated date (so you can just transfer two files to said static HTTP server and trigger an update).
@@ -343,11 +343,19 @@ nowish = datetime.datetime.now().isoformat()
print(json.dumps({"builds":{nowish: {"time": nowish, "client": {"url": "", "sha256": ""}, "server": {"linux-x64": {"url": "http://localhost:9283/SS14.Server_linux-x64.zip", "sha256": ""}}}}}))
```
+You can also checkout our publishing script [here](../community/infrastructure-reference/publishing-scripts.md)
+
## Systemd service
-To allow the service to automatically start up with the server, you can make a service file. It will look something like this.
+To allow watchdog to run in the background and automatically start up with the server, you can make a service file. It will look something like this.
+
+Of course, configure it to the actual directory of your watchdog.
-Of course, change it to the actual directory of your watchdog.
+If your distro does not use systemd as it's init then you will have to convert this to your relevent init.
+
+```admonish info
+Due to how services work you wont be able to use the SS14 server console directly from your terminal if need be. Ensure you have given yourself permissions on your server so you can use the `sudo` or `>` commands to run commands on the server.
+```
```/etc/systemd/system/SS14.Watchdog.service```
```toml
@@ -368,10 +376,20 @@ WantedBy=default.target
Now reload your systemd daemon and enable the service as you normally would.
```
+# Reload the systemd daemon (required when making a new service file)
systemctl daemon-reload
-systemctl enable --now SS14.Watchdog
+
+# Start Watchdog service in the background
+systemctl start SS14.Watchdog
+
+# Enable the Watchdog service so it will start on system startup.
+systemctl enable SS14.Watchdog
```
+If you are not already aware of how to use systemctl [now would be a good time.](https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units)
+
+To view logs you can use [journalctl](https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs) from now on.
+
## General Troubleshooting
### Server keeps restarting every 30 seconds
From 6148c9dab6e3db85939ed66a4095980fa358cfe1 Mon Sep 17 00:00:00 2001
From: Mithrandalf <84274729+Mith-randalf@users.noreply.github.com>
Date: Thu, 6 Jun 2024 22:54:14 +0100
Subject: [PATCH 69/80] Joker Roles: Gimmick jobs that wont instantly get
annoying and boring (#224)
# Joker Roles
| Designers | Implemented | GitHub Links |
|---|---|---|
| mith | :information_source: Open PR | TBD |
## Overview
The core idea is adding a diverse selection of low-stakes
roleplay-inclined gimmick jobs. At roundstart 1-2 (map dependent), will
be randomly selected from the larger pool, will have a room bespoke to
the job appear in a pre-established 'template room' on the station, and
will become available for players to take.
## Background
Gimmick jobs are a pretty common thing in Space Man Games; various
servers in ss13 have barbers, boxers, clerks, journalists,
psychiatrists. In my opinion and experience these jobs are divisive;
there's often a handful of people who enjoy them sometimes, and a much
larger contingent of people who point out that the roles are dumb, often
completely unintegrated into the larger mechanical ecosystem and amount
to little more than a greyshirt in a costume.
I think the key is novelty; these jobs are often fun to play or interact
with once or twice, but quickly lose their luster. This proposal is
intended to allow for the kinds of fun roles people want to play one
time, but probably wouldn't play every round as, without creating role
bloat or half-baked jobs that people just use as assistant+. This would
also be a good, low-stakes way to trial new roles, or put in roles that
are kinda stupid conceptually.
## Details
![lil_room](https://github.com/space-wizards/docs/assets/84274729/47929eee-2904-4fd3-9a2a-0b78da828009)
These little rooms right here, the kind that you have in hallways, often
near arrivals, would be the mechanical basis of the implementation.
Similarly to how tg13's holodeck works, the idea would be to, on
roundstart, swap out the contents of the room with one of a number of
pre-designed prefabs. The walls should also be included in the prefab,
as this way windows, counters etc can be added or removed. If joker
roles are disabled by config, or for some reason don't spawn, the room
should default to a standard Vacant Office layout. I'd like to specify
that I do like these rooms, and dont think this should replace all of
them - maybe we could make a few more scattered about.
The rooms in question would be unique to the job. I'll include a list of
joker roles I think we should have below, but some simple examines might
be a veteranarian would have a simple surgery, some basic meds, some
animal boxes and maybe a defib locker; a private investigator might have
a desk with a bottle of whiskey, some glasses, a wardrobe with a couple
outfits and forensic equipment, file cabinets, and detective-carpeting;
a store clerk could have a shutterable windoor counter, sellable stock,
a locker with some cash. In this way, each role would have their own
slice of the station, with access to equipment they would be able to use
in a way that feels integrated and intentional.
I can see two ways this could work across maps; firstly, the lower
effort method, would be to have standard map-agnostic room templates
with a matching footprint - all the mapper would need to do is ensure
that the room matches the 'joker room' dimensions - say 6x4 or smth -
and mark the room out somehow, and it would load the same room contents
for each type of room across whichever station it's on. This would be
low-maintenence and scalable, wouldn't ask much compromise from the
mappers, and would (presumably) be simpler to implement.
The second implementation would be that a station mapper can opt to make
a joker room template distinct from the default footprint, and would
then create a bespoke version of each of the job-rooms that would fit
into that template specifically. This would allow for more variety and
freedom, with any given joker role having a few different room styles
across different stations, but this could also work alongside the
simpler method as a default.
In terms of job selection, this would work similarly to how
station-dependent jobs work right now; players can access the full list
of joker roles in the job preference menu, specify their interest in the
role, at roundstart the jokers would be picked prior to job assignment,
and the jobs would be entered into the selection process as normal,
using a spawn point within the room. If a role goes untaken in the
initial assignment, it'll be available on the join menu. The jobs will
include their own access level - if possible, this access would be
dynamic; only appearing on the HoP console on rounds where the relevant
job is selected, this will control access to any lockers and doors in
the room.
If mappers want to go Sicko Mode, template rooms could be placed in and
around other departments with a selection of roles from the larger list
they can select - for example psychiatrist, veterinarian or plastic
surgeon rooms could spawn in or around medbay. If this were the case,
I'd suggest limiting the numbers so if a role spawns in a
department-specific position, a generic template would remain empty so
as not to tip the scales.
Most of these roles equipment could be designed from existing clothing
and items; while in some cases it might be fun to add new items for
them, it absolutely wouldn't require any item bloat and could add some
more use for items that don't see much use currently.
Seeing as some of the jobs are a little abstract, it would be good to
include a *brief* flavour text on spawn to outline what the job is and,
probably more importantly, what it isn't.
## Examples
Here's some ideas and brief concepts for some of the roles that I think
would work well here.
_Clerk_
Room contains lockable storage for sellable goods of moderate utility, a
safe, a desk with some basic paperwork supplies, and a front desk with a
windoor and button-toggle shutters. Items in storage could be drawn from
a random pool or fixed, but would be maint-loot tier; yellow gloves,
syringes, crowbars, white medkits, toolbelts, plushes, nonlethal ammo.
Intended playstyle would be trading and upselling until you're buying
and selling items of genuine value with a safe full of spesos. Could
spawn in pretty much any outfit, so long as it looks civillian.
_Plastic Surgeon_
Room would be a surgery with all the standard tools, and some basic
meds. Anaesthetic tanks, medical records console, patient locker etc.
This role would obviously only make sense when we've got newmed.
Intended playstyle would be performing minor or stupid surgeries
on-demand. Would spawn in some variant of the medical outfit, intended
to distinguish the surgeon as private and independent from medbay at
large.
_Boxer_
Locker room with a shower, seating, some bruise packs, change of shorts
and gloves, sink with a mirror etc. In a larger joker template it could
include a small boxing ring, but would be unfeasable if the room is as
small as I'm picturing the defaults. Intended playstyle is the same as
the current boxer really, would spawn in shorts and gloves.
_Magician_
Curtained room with cool carpets and lockers - might include a
teleporting locker. Starts with a number of prank items, some chems for
making smoke etc, magic wand, a small animal of some kind. Intended
playstyle is basically a variant clown, putting on shows etc. Spawns
with a top hat etc you know how a magician dresses.
_Gambler_
Carpeted room with some of those green tables, decent starting cash,
dice, arcade machine maybe, small bar with drinks. Spawns in a hawaiian
shirt with obnoxious sunglasses. Intended playstyle is gambling away
that money obviously.
_Private Investigator_
Similar to detective office with different noir outfits and no gun. A
desk with whiskey and glasses, CCTV monitor, forensic equipment, camera
(when we get them), audio recorder, bureaucracy equipment, one of those
emergency sec radios but not an earpiece, evidence bags etc. Intended
playstyle is a second sleuth on the station, can be hired by crewmates
or can simply try to do the detectives job for him, but critically is
not a member of sec and isnt authorised to carry a gun or anything.
Spawns in a suit maybe, something noir that isn't one of the
detective's.
_Journalist_
This is basically already a thing on some maps; room with paper and
desk, camera, outfits etc etc. You know how this one works.
_Veterinarian_
Stripped down doctors office with some bruise packs, ointment, and
bottles of watered-down pills. A surgical table, some chairs for pet
owners to sit in, animal boxes and wall defib. Intended playstyle being
a doctor for animals. Spawns in something medbay-adjacent.
_Centcomm Liason_
Room is a fancy office with a wardrobe, nice desk, centcomm carpets, fax
machine, camera console. Isn't a member of command and doesn't spawn
with access, is there to monitor the station and report to centcomm, not
to take command of the station unless it happens organically. Spawns in
a centcomm outfit.
_Psychiatrist_
Room is a psych office. Again, this is a job we have currently that I
think would benefit from not being a permanent fixture, but would
function the same.
Anyway that's all I got for now. I put it in service cos its mostly
service roles.
---------
Co-authored-by: Kara
---
src/SUMMARY.md | 1 +
src/en/assets/images/jokerroles/lil_room.png | Bin 0 -> 31761 bytes
.../service/proposals/joker_roles.md | 84 ++++++++++++++++++
3 files changed, 85 insertions(+)
create mode 100644 src/en/assets/images/jokerroles/lil_room.png
create mode 100644 src/en/space-station-14/departments/service/proposals/joker_roles.md
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 8fb29acf2..3e43b6380 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -241,6 +241,7 @@ Space Station 14
- [Proposals]()
- [Plant Genetics](en/space-station-14/departments/service/proposals/plant-genetics.md)
+ - [Joker Roles](en/space-station-14/departments/service/proposals/joker_roles.md)
General Proposals
================
diff --git a/src/en/assets/images/jokerroles/lil_room.png b/src/en/assets/images/jokerroles/lil_room.png
new file mode 100644
index 0000000000000000000000000000000000000000..346bd2f7788a5958d78bf8dc476908253beae194
GIT binary patch
literal 31761
zcmY&JAgkdr@2-){-LfOU=vTv0k#@1q2*6hnr_H9a*vdg}Q
ztb;KIW1rvC@_pa;_s4wZ^GwZno^zl3I_J8sb4O@vs?eTeKX>ZXDcbw0_jFI4I^BHg
z6a^*dEbvLc$_+Q@$2u`
z>2}xrN2gBt=ia}kr0-+7-bnNAk&y`rF*G%#zSH!ex5-vA`H?NdmCsk`->_xPy>Q~a
z_ESCl=ectyQ>^#&wNJN>oVn-2+%I_LN;r(7rR*v{55JU&9ilFel$JIn`jGOa6GJ!v}jJt#2qmL*NsdE)nnJkmU}@cuK046pggJE7uitoyUv`(Q$ReEggZ
zGxOY+$+@h+oa@)Gj~aDkNzLRmk8wTeq}J2Z+a2oAH!v78N`5|1G0M#ajh&(2op(jL
zvIeh>N)WJnNA0cTu9r)#A=%{81!a+}IXY~)VE}}S6~DESNEbnFGBZL1xx4Eg9doC$
z(7g}~CW=>#8L1%<>47;%$EluVGM;iIe5T$Tv&Y)-^UR#@F(%+BnA{(W4xX5pz82(>
z%7r(=?nLcD_xD9wFs#^pnfBJ1qd+4xzA=AkiIRKo+1`Xp{R7Bn0_LcI9tPs!`Jx9d
zWfrV%%)Wcn_cLQ}XPgeW?O;)%s(Jjz3OIQ4rxGEkqik^RWx5Xh;0yjT1Km}hU*Et4
z*C1kQD~378>o|ChF`b@VH`1tiR2p5FbFvhi&P2|f!D=4)5f;4_c~4%tG?*S0SQ-?M
z;zzJ2J98HKAQ~PNDrLD_W{MyEq|ps|&nl$7cV4ELM7Rs4FuFAD^)r7@cY#rbF5El*
z%IHVmPl1(HaUDBQh$Jsp`7Oa_aubP$5KOLTx9Pq_D)<0XWZ3aBy}EWJKeHoBfChXD
z>JbpPzrczvE2%VSIM2+(gL0pztIsBBeQ#U<71Dx=+
z`SHDMQv)YY#}}69XCqLa*%0(AdYEc{MAN|#CZQ1G*fwJ6U*f}{$rZS*LnvjK#0F!1
zHb-q@Bd`kzW-as8q?jH}f>;P8rqpFo!+)88U}B_>qXFCd~w6_slzG
zpQ@VCybwqqG;}GI{I#Q{x|hMrkD_OA%=*q=CI}mhs;{qaef#9&<4zXf&up(s@C)*>
ziiNvQRosWv9B$ON)}za`H4qJgCj>@;7UF?G=%O{=;ZSXUh56Q1srgMgQ_aHqVymmF
zJI*$U>sgRuhXuMSO1d(O>dW3xJ=_@UhS%1E(DhdPa+o(&{lG`J#K3q3eH4lw279pm
zpnB>W-SEp8#~^JRn{41|+uGV%TtAlAbk}=FdOO(L(
z*Q|`*r5ZUHKYko*6r2}n`D3sN8_roiu<>K`LB(K|%Xfs=mCs0ZwZV;z(ZS+95zDT5Hr!6=@%pU6Jv5@91?|=z?
z;au00i#9w77gV!(Ah2)SC;WwWcO=%a=#fj)O6c5umjJ>BCh}$4W%hnVs$7+00~GW(
z65Wr{n_1DbubzAy%f`UP&r~5tIz+29-^*P+Ily69p*KIw_xqlPgO1{?>N#cbnJ>8*
z@YUR()h}%Ue`ay}H9lgd*1*FO;XZFg_}L!3dF@ab>*RBcA2Y(;CAZH!MhF=xEaj~g
z#rv+#2A5+b=Rc8&(uZpMtBonh$*B_AmI*p4?$iHL@O~xx`!YUJy08jTaF)|dlLf@u
zcgN88aUqqGHXIcC(l9N3zss)0U+Aj_GtZ`O7^4@~=lE@a$L{^(p0&{|^yXsf(??-2
zA*I9}-7se@d#9UvFN9&I9`7+1f&7bkCj;VRAYdwC7=QY>WG>Nl>9U~DsZx6vuhw{
zgx!eV9a^O_cwzadkX~F5rCd&+beqLaSgHA%PB?u{>7OSpotB~A5I@G=EK<68a9IWeuPF959z~
z_nYb4vS7=jxj|Bdh37o3MJ?L92~TPrJ}-5Vug$uPMez@=u`7bU7bZ19`^ii0^z%eL
z^Nj;zy0aT~I5CNV>?q*X<;bV)v(EZCsCMBLc8BIW2Uod>;1~ZO`ndIu}7n_9#Sd?${Wi(ZI@mQsUo=-H&x;!oRFX1jg#4+w&R3*mAOPCUP4YBSFV_
zsAU-j^gVhb@9B1gvlr?h)iR53&}N&4k^3eav;Ca_`T?waQH&{=DZgF|iyNA=xIy+l
z$=7V)#-FSU0lT4Ld7O2^sAyiA{fu&Y4N1|Ucd2J5a>?g65UJkD2i<44L~nX<`J#dL9b1A#*^-aaW%49*sAWBB3)1SJHlOGvL>m
zdG6aZ0(hbq*2Tx)+T&XUsy=K1eX$@ZIwKw{=br03FZeZ`D+sd}>~!o*$Rqzk?Y+n5
zNOTSaznchWt0qsZ0~qkAkm@wkY+#jLvL5g%`2()1H-4`!ZfGPw64BK+CB7}aTIJ|z
zmiQ5)^U?5K@DE`a@JTl4dAj6I{4@8WXH?6d@HjSG|$<
z7gN4KU~j@wRc?>Dn>QrRZBh85v>y^8jlxNk=X#=aT{k;Kw#PB~>k8L&fYR0K`Uf1{
z0B~fs?##VNs1Cwbo!ikvS>6#^WarqX=#Usm%HZDD4O90;6@s+Vam-j}>>`Nz`TxRC
zN7z2D<>S?noyN`aQk@r;j!$Gm$HifH;QYcYMfvod@#zh2>Ba@bzH~A4LZtE5Ap6(-
zp0oc49tQb`;>(@Bdj^W5J+YwE{lBJ$jEjW}KyMA5AbaPvBHr(n_eNSA*U6x#PFg2g
zEWLicw{F#h>pFA1%`-{JtKC!N1i<cSUCu~KmoM$?I
z&O+ghm91_{dAqQq72cU_6N{dCh}9d4Pnq{3J`iU@6t~RFxgW1Z?Jk*d4os)A
zyv~04BrjgagJ|5-xWt>M6$lSKXw`4Hd3@ZVCYo2MTg@1~dPsAKN~ORI@v~Or17NkSkGOD&l>Yltiy3Y15e?x*PwdKytfT
z>-lLx81yRWTqSpV%mOz4GL1~gl-~o-stPnlTZu8Ed$mNymf0Ad)5v_6LP=uGzl2%y
zHC#TJr}CY(oj|`4O;@$lyH>r4)}#DDot1CdgO0nc*7}HhjCBE_7N^x*taRp|5_gk-
z-b$)$y_(LmDzY9ac(L!}!+5S3?;uCRqY4GBs-$n9Tfqb~FY#zO@b-z;-@fMq)9hC|
zWb9&ebo5-~s|zRmIa#2ocQrXPdEeEdqN5{be)pzEUZ$F-HOc8fKIr1fl`7|d)@|qhb
zjNDDQ6GdMxDR}p14!u;X`q-Ih@ZxzvC3EuB)YKde4PQY`*4^3}a=|}BP=q*kETG8P
zvC!o~Q?r%Vn}nadBb6dMs%YtO~&I6a!5IMlW%4R$`cpF1?tYwK^=kX^%vH0xoGN
z%>R6U>VLjJ`}O4j6Hi)FKKPxyw36*`p7kxEZ*uAjX_3v5XHo=NMQ
z-&XA*z;}wU2SszSfp-rL_&>brs>ZW$R~BfxyjE<91{>
z56n`xdapY%|H%Us3M33u0at0__B`*}jH@hcJQyea+E;w99KF_@QKjtYI;bdSAUy-g4dBpmC6x}5a!*W2Z_r#A2-WLK0HG}QDqhxV4;@V?Ox%3
zp%q5OoS6-h>3R>QW5?Od^_nNK%nZi`9fjs55@KUZCR5_#
zWWs4+G#g{1Vu~{mW6$`#v^3z^&n)`(`ltDbXIy9;mG{90!d3a*v%FOyaaP5W$E+6@
z!3@6{EPomA)58=I8TekxNP{v&HI18qINEfLL=1M{WAGZZ{YBg!g`^L&L>nHkIxzk8?YjK+|+&p3;k3c{C#za+ZW@ShmBTM@J%1eA}A?cVFyfO|*p
zy{CnyBOCpt#V=GqYTc3g3>VGeH6CxP>dprFq89wff1<_U*kK6HA`uE8Ld{yin=&o+
zzP9zZ9Mep^v6|IY_O*duSA1Qx`TKvR2fk)*O|UcCXrGbE8u4sm;$gb7sr!Oe+>(hr
zxu4f!(`e>W3vVz=n>Cv`F+6m9+;p7x8(Gur$j#JiMMqnoDe1zoKu6gEJpmuPFa(>!
zmlv52D%nLx{wL{twrQ%BwTtI<9&_-u?D^kr+VwIx6&t)yj_`H}M{2A&VHRsEZ?5{j
z_*tI%J!$aeb5<_g{5ouDU+KB8P@y~YBtQrz!vgS|D|_a_Z+$RF%`-=2u5wIVL}=`o
zQHQCp(kVD-AwgVmJCiOVkN1LR6SGzAe_N3KcV3>1i(80rIgJfpJ>hgckSFk)|4LC=
z7M2xM5WMp9&Nv#oSc
zcyf0v8o|!0VWX$2)hUhWri+^xD_wX2OT>M&Y^NJOfcz4P?NdKZA$}EP4i6vBw6Q5X
zWdR3eT)^)$9;cOFwM5gSd*~|e9fczH&Jc|8@9~3RImN@VUUVLB*Smlvu1Xt@XZpN=Y~c=lFJZPsPHx$%Anz^3a*3(-RgB)9zp0YpvrlBnIwANjy9NN!!L{
zq_dkxx3yuJaE+tLv5PhM^7go^5s=1>c8Q>lXyba=htqedHJsR>RdkW;x-ZZga5TD{r_vHW07-e8){;x>7Ny
z%y#LE?8%8vW9g@8a9z1l)Y;jgltH>;QW`Wk)`wNbwuY-*=@l}H9_Soh!M$u&8#iKK
zN&M!6za#^gXU9I-wa!-`xErBfUgTsTw~SO&-EV$S>Wezn(N{#*@5DUo_lw#Vjo_Lk
zHIWp6e4X4mIlz!jkLqWRT?qQ9FElACYzhCR=3V%5CP;;woV5olpZ0xz9r|gDsKCV&
zmnrYwkZ67V@#rTF!mMy}H%DP>$a!!h_urM_;l)vB`ZmuAnVm~wzu+iQWTl*XV{vih
z5%QbLUB!3x+>zfs?7O<#%^b|e*gAVl0CXFfY2*juERjtW9k?Vv1C}bk+d|hFnn*ra
zYE>otv?M3%y8PD;gwZu$mYCnM>S~I=F~4_dVpLba&;-m(8L|JUTi78fc0nq10pq%#
zOtC=i(zs(NA*i%{GlX<{*rO!wN&J;~faF_}twQPkQ0Qwo!|V)2E>^@^N!TgV^S+hr
zjVrmSEy2fny1d7>LEe>pG(t+
z*>j&lOO!teAbe37<{STNEiH5AOJ0cYOnd8Lx#j+oE=u#%t&l}9iz!Xrol7sQJD`ua
ztO($z5ZIqCho4Ft>?hdVjy)o`P*!MMX4eZX^ViGXBL>P%P3JCHu)SlNVKU0m)eF^O
zm(&w9)lwI8J$`Wv(cT#D@gp4Hl`~8;bMem}-rO46l31EgAm3Np-aAy@uG`f^g}QuS
z5r(q1oa;@8il4Bil?1*i70^cQFFvQ{qSu16z01hf(*BFkS8k&FFc?{J_?`#0NObaK
zmu`TV#*Q=Ce^+}$w5jAi^DAy`<1yicvqd#MyJtmY5Rd#PGX`UzdT@}2tAt27MCQp=
zNrQk>9lbehaaWS+PXyMB9(GOm(`?9EYJ<-T6r=m_|FuR>wrS|#;gDw1@z-8-aC_>B
zCWMA{pB(@PAzO6`A*ik#fD~nu|0kZ=peX`q=0w0dJecenq#sblB#iIoO0diB+UX%t
zhEB)A-oFfpRZ;!sHz(X&Vj;)HQ%ctOAAsWZ+uO7HJyC4^bJsPnrJU0M<9M3H#VAaSxDto=G|&f3Wj!
zZLs5Z8VttRlb9t<=G)qiI=ZVVwyjHIxS3WVajCp0-Ya7|V(G!arv1yoE`2e~j^Two
z`T5M}GGgl}d}$9g%MYYl>x&|gs%;!@srSDe@`fARA*q(R%ZxvtXr9qWVFK5Ytv0fP
z&Ei3O)vbJNIUaA9z9`qOt*Ab4sJwN^0ra+~It|8Bl0KO}ENj{@U^vXOyVHrcA83$`
ziyThY@xL7OuwXDKY;CVoG`7!xYQyKL*lqQK-iUPUo^C6iNSC5wEJg}e5C-6f|3jQ}
z)D5$LrG2!_Dr8UVq!kmP60J9KOM*Yp)6E>2Az#Pdf+&;zG0ZX*+ho;khK!y_yZlP#
zWnrPGk{fYxl5k*Z_Vj63la&IUGp%V*C8zj}8$9wS?#|NZ;G0{>ZC1LElIi{d+5xpe
zCkx|_aew*mso$NCot?q=8mDML>iE%LB1XfGB^=PFJfk#ZHP&Sfe;nI%SK-0Iw4cip7^#6r@ObNa$*j$+Tc8*2@z*x49
z9isTie~~_=kBZ@)WKa-jVhFSv-`RSQJ3sFmpJo|rM$zftO>JD-K1LUZSe~aIOM6)<
zcOs?0j=Sy+|J<9Nj-7?w!@vByvf+Xg{Q@5iP#lXr;UwPmMinJ^-wWkZfJSN9BRiaL&6M^oPFO)1h(+9)GX#M(hGjP@t(@KKHja(*sf-7c|H`syL>A`mybSk)DCj@Q|*6?Sb(%R?w3ik>|f937#g2W{;&lw66d1GwRmyL!YX7aF{~ulbMX5
zw4WUceq8CYndz?OS|Lu=l$$60hS4VR$f)Jds^$$N1ZsuYE6aX31=_TYzQZ$uB#15+
z()>T1fqe$J5NhU(UuyM#-T*L-=G#b@X}urO=Bh=oi@zyAqD8r=igd_
zzL|n|Nu;%?N3c9DF5|^6rq4G_ZRSUMA=d%mxCymvroYox~gPUB9
z8{}yv17}=iU#)wYpV;iZ*>g9b!Z;xr@U5olWQ`e;shHq~XAu6V#wUQBMYHafV-5|*
z_6z(Kwdh|}@?K_RqbFn2kEsc*9kk-uy8(7~c|K71^3bQKncM!MS=tLQUkbsFp10%K
z)OQ~2w+HbB?k6jj$R6t0s1&zvg{GYybD{ouT-~5$J|_HvuJP`>rGEk4PxJZ`u$hkU
z$4xm)%axhg5HcqH697meKEwal@1H9L$&Z_@i##6j2-1e6eRHAxdZx4XVWS=$Id<<$
zCYT^5(=?|^SYJ1NOVmSI_3|C{+eY87D`y1EkPlzz8gy*z5eG?aDL0PySa%L;7a#js
zjySSEs^@%0g6@52LX@I^mK+*EPcoLkR2Jfhfep`aho6@18=fco{St&{{~_KOqcJ!u
z-qzc@dhd{YnBGchbecl&OG$kx1KmMSI{i$gXRMEg-8s`x*d+?VmJA6PkRb39;}3pg
zDvI1~(n#n2Braji0ti;W$i&T;+Bb}|%0S3;>1?;uQzA%5&kH$fU%3=&glmHRO~4>y
z(`Y}=;65VgMQI|&LA>mpKWDuJY!O_Vrm}2%`fqJ~d}kOrd%T0}ENxyEI-G)E~CD&yT
zmXF|>#0!mEAf2~o!@D7e(Fd}pWWtPBQ3|nTgHOz4f=M=rQ;r=LajXMCN2$h?QVnaqm~R=hbNr@|imB!CDU5?dhr
z;Uo|VcD|_A3WLWgFHgMEMU&e=Bt`to7H+wxstt&!SH7sCC2-c##THOMJI359s;oi@
zsS8|uy`Z1%|6VHg$qoc2qs&$<(JWiVeiit2wZvkxXzT3=40)-&g%Vg`mW7gj&><{mFm)?Y>DztKWa=?>hOtEQt5s2oWuY}aF7
z{V5eflpllWQv^iPN?W6JqO_xvZ%8*@@p7;h>(&HFLb6}zu;`B!t|a=@cPXqK>F*d*
zHC&Kazj{e1Narl}sMLCVKL>CEYt}aHjh0^xY`Zg^WmEBsm!!_o3->*A{L!Z2)S6VF
z!}0YH#Uxdu={7Yd=Y>I-llHiN`s;37CvR|^7x|~d4Aa4gsUkt%-Der+J6k2Mmbq8H
z!3dkaw&h4!ZRrx9@63L3-Xqf5Le$gx+eA^Z_SdaaD_M>CGr1Dn`_C%N^V!11uA{Aj
zJPksVxJOG_T@>RZ&ag|Bz@wAdG9?dd$UR7M;KlPMK9HxCQE`UNOSvl+1ux?YOM`xH3nM(@T^A+xV3v
zFA^Spn^QTT)X5EL)I&acjVUPFOWlSvx2BJ*&mMQ?LJI~s(ub$}GpV%FAXleFVsGRF
zRduK#8Mbix1#F4ZZ`Q!2vgDFv>{LVV1rqR?H8F0CERVOo(BQgrEPXngSpn
z6SL~`f)ucYZ>dN38NBF6rVJrU)Tq$n2azjyfi%_Lsr!)9g*8aY;U|BR7$HcF{tme5
z*Hv+FY|67lUZ?lN>!rgVB|)KF(7wowg_MN6vls$sY($XRN@$LmZ+jKFJ?-1rL^u{9
z5kN9ttAVVf=V(n%@nQT4-Ris_R?rI$YS%!L83;W(OHfh{_(latr|t%*pm}hq(Mh^`
z=5B~DYDF8IK%Kk@c84@?6aJC>-xX>Nhhrp1_mZK6&zRnR*jtQYwi0nOWv;Nxu~1*f
zBDdX1>q3ydg0sW%nM2=)&?>LtNIbW0>w7%po=ohkz-V1?f~2Jc4AZ2HP42^kAO6=g
zuYETKTh=^Lf|$m>=;)Z-nsYy+1@t{wp07>H09F#?$*ec=eK}u*dp|Yqf4}?GjR?BL
z_ks61wPZ9{GPVrD%yak$I1G7!tRs~lU7A2Mt+@=av)y)R7pK|?_*r>*nv^=-UmTdI
z2+1mM?vdy|-=PnD6~I)nm*}zz8g{-%Ts-Z3zs*mW3b1tN&UN5?IalV-QyA6y&Q_b}
zqUi@_%IB}11tR5(8q-}qx@$H|aC(>Gu;0a}0sI8yAy?*H(1}@n#e-8#WFU6`q>6i?
zIxn}YhbVf5Evb4S9Y
zSBfk#&u(yXi}lUpOO!7AZ*>;~9LdoXsB`8q5hZL=(vCK{VbP|ycv{bu>X}#9#8^C;
z5+{pscwBm)B;?@Xh6QNuUn3-fOEJLbz8L@ao60`F$6I2fks{3jt)S=i4f5PI60m2(
z*`s6)8hGUTCt0hSs^nvv0K@0v15X7|wl%Kt99FB%L3H1V&xdMFnzp4E^7KSoEE
zt(gXlM}qVP=2z7tw!tBovhxpXh0Pc}49{N})*3Qfk4!r)ip_pNJgehU+%ddNum99%
zH>!>4H6oPd!{tm%tt-q{4zt2a6>K}~nJ4wqE21K=Rea_(*WDbRXkf^%?^|H})$ktL
zhM^}-luqq9f4ZynIhuHn61OQ#jIzRszZNb~VuAq51mTK#--%1Y!;j&%l)r^z`j6*K
zM4I0UNGF6jY~P@qOyXhU_@=*d8uFzv?pm(LI&!djD8IyaWjuE=2O}1PeBku5#Lcoy
z`qMCrf@|PcxgHbb>S?O?WBuw=7DwJZA;*tNh6aOh+jzC^P%XyZ$`|rie
z(#M2hs2^7*&DYlAGKd`2eg6KVZ`2Q7M0!aKKItSK5Z!t9A+C-rS!^dS_RB%TOq6N1UuKJ|a#0!Y&18D~d3P$mzfo(o+h~2;Ry6
zyzuamt6ugkTgTD-$BYc9@?U3stGrgm<;~1)ONamMCs;8!uB3qag{q_as!8^uWkefI+a$>3|olR6~
zP&TW~lk<hQ=?IqC&{54)cf-*=2}
zH`v@zDApNJ
z=cR`WF;xR^t4svq4E^r)P6n44CB8u$7!;nev-Nyn1Wvm&a7Zi)I-qO8uE7s{Z9Ar&
z4+83DsqswMdfnJ|gWP|u`9t{ft|C_g1Xh+*IJSKL7xAGvc9`Y3`*O2v{E|)Lr_zU4
zX7ayQiG5v)b7%q+LBD~L&b^zDYT@J>4%b6lV$TY#fNDChSK#UJa6#Svgjy>=tY(FL9)+*4#^!i3Dbw55=gq+JeiarZ3k
zePtkEOh898L>C3LHk)X$-;VSFz$JlUL=v9-IV%lw_hl&~^vRkPVL)ffl0S>csIy+4
zQ#fA5{{AB=I2CVXM_1OvwR8jJwOX@tz~OW(O_*pu(LMU`mU~pDUaO%9RNr(GIM=vW
zGQ|zX3&YCzc0c%ZdjXyhaF6c7Q4A>duCv5vz2)wD^jnpP+{MuG#4m&SQC5>>9giOL
zvZ-F@Z>dYcwUjmJ^kroQdUXxH{Yy!!y9(b-++3{X?%A^)rGskF`ua|`4CY5)x@zAg
zsAQu|6LwWoRgKj=ug1lVbH48Eh9_O~?s4qBE?L#_!Dps73vNW4wDB=ot1oj64H=-}
zUH0JnshS&TiENcbGH*U>s3CSfDt*+Wz%sQPTi@v-r*3a*q$E?DUsHap3i=-Z4q#`gyxX08=70}}yuD|_
zrHGh+vH$#d*=gkXRP9FlC%f&;xvJbwKrAexT2M-&^Z}*3wC2eGO1}BkkUzvQD4faP3q{joa~QR3}c0K;();)HcW3Dg7qMWVhlw@XOpp>UsW
zv8j!*??=MT>(U32GXXH@Qqq)!FzjRQm9wC$Nh11Ts8{BhyxZUSo)VvWxeTW8`@Omo
zy$Mv$3|N|GVOUb(>k@OR)anTtQS61~_fuYDi4>hy0Et))+NN6xsu*p^2}-RVv~4FA
zmYUYagv@U_Dj6>K3;g0qYB@Se);gDSq2N!CbP%lw9>$Yf^DSr0svHp6uY(Lwd;qGT
zwbReu*L~@L7==8lU~(?`LCPz+hT`3xe`bKPJNE&USIkQ#l1>ZTx)688`q_S1$1D0b
zqWY*(-ggFYdseOEDhuwB`F2;LXtdn>LQsLoZCW>l(oc=1*$&PcWQco?Hs2tt8cp3V
zvr9ms_=Cv(0!_8~rq=*OCa`lR2Q4uhMPQ%IDG?ZfNxUQlUHQFxZ{oE+KdP_{m<+qI
z{(19to+fVRCEF~sk%jolo*rEU)L-q8LLoqvd1XHEV1J?2QpN
zp12HO5c{rjh0)Dn{PLj*>)k#
z$?V;XkTNrseC|tiSArDdx${XO_m~==uHKAe4tiNoWC+jqp12y5_OV1gu*N;LinsAb
zy%B`Ts&pRgQY6d6rN*rdek1*O+ghWG(Id3ZXvH0}NZxAwY7Jlp({Cr*CBjjoVvzX!
zXj7Q9*>LhM3B#6I1dJ+_f!F{#I!Xmg35fp(#wl4JGY|m2AGcNq5I)@w9yx
zp-o*#vxR0MHq&|X&+?Ha7n#+lMO$;`~Z+>ht3FwZ`fNs(w{Ez+hDJ)Trxm7VZF
zwfx1uw$PlE9E8798%Sn-Q>kggu&tirAmZrs&`0gMWV(J=Ti3NWEEq@n`i3mWxQs%j
zkcfL?vC1iIndPa$%e2->J#oQ%hgdbKpPKbuU83k@k%#*RpQ(9F7@LlFWzhRu3P{V2
zK4}=}JGc#$tdgXh+0J*b_=*4AMZ%(;&Rt=zHAA8Gcdc%LoHdk(jq)v*h7d~bttjvqf)C6O>q
z%g4+kq}fH;mvs2H^D*=bFy`u_4VFXqxk6ytPW#Y(;p)D5ux&9&C$weOM?(*M7SK!B
zFLihU|6DplmKsPw)Vikc?)Yxq@5UiZM~IaY=);DpbL&Mz3#+`hFi#eck$48uV7D1r1EwqDL~3m^#{X!IP!YJWc3GvlByczl7FQ<;j#ptNj-y;@ol^OF5CqW*!m6`j$HFcz1OcSxq69q&V
z=+lA7)}v=z9^H(BO7&3bAx~?4)Ca*kbW%c_-4s1HZBVFJ0blwBl7OsfYUg`OaFkBr
z{pv<@eyUyYVNw6qsa3iX6_0SW&WBAnR%#8GhuhLt
zOb}??jM(0_+B4t5R14Hg$z!R#oSA}cb@9D`Bx%|B?O{`@N)4Z_SWB4NLSZ_=LG>OrN8omghN43O3|8B{bp{4@9HxD}mn
z3~HmyvthMTbDz#Ae6f=|G4g0!nV4F`q>Xe`u<&+1nbABPOmKYRvOiH@LA^J9dO{_m
zx5njx7?
zhjLCX9iE3hs0@PQkgZqy*XLa%Wb+1u-ldt9O=bi5O~UK81_kM2NA_2dPwg6klP4vd
zI*8b`SDwvJ3$9HSCR0EB5p$K>N9598jdaUd;0cWKK}29o+R@hefvJ?7hmx6z^f1o1
z=%e(F*aO7FNw(*ReM?yt@hC^6_+VTnh&VJN_>6awdoXu%E(rD|mMtrO#ztSo+X@8R&mBGj^8!
z(-hv>`pi@YSBDK}mV#lbRb@kh0D;)->0U
z8=hT&&V_%;95wMslYT}0tUlTd9`khwGS
ztSlWcW(M|ay~s}3fl&INBIlJ6b$9L)c9gi$H)n62I$pos8XP&rnwb`fl?uewNqQZ)SEvR=Hrx{+Yarsi;@v{8@Vo68QGzSjW*!+xy0IuI@
zYm_!BV=|71X*OEEa);a0B1U6%eJF^Z
zI%hrmEZ-l<7!-ml6PRM9khpZc+Hl~?#QLcQy2m?PNPUwi&D-cNKg=;|b;g^2
zR5*bRTXnBu$0>X=A_x|K|%w)~LhVc4@LPDIhv$=0bHJ3nex{>rc*4y-vwu3dUVeO=D@&Bp5)bb?rq46
z4BP^8yz!z0?Idoru?KM9I*$*boDR%b2jKi$`(cH+;qoJ+>eiCEA>Fr~SD(tU3=os8
z4Xf!f{rdxY>_~*1nV)&QG`oPNbv8g#?4oC(b6Rt9oXFxMW`FGem3=Q}c4n7Ou
zx)MU)*QoP;8=sFV|BtDy28P{_7v69SSmvCA#6p*Ssgy=KNfqZ8DUHA{%9g-AG7iXo
z%KD1R#TBLKGn%GnsCDa#HJQ2MkT-43ipII@%rms}@@^*GmZx^k#Yqnq@j6wIa6+E1
zZ3YT2e99TvH4be|xt}qhKgILk4fW}u%(9kRjIzY<9DPGvk>nKUnmR9kC|UMyB;eVC
z-@7fkUgU%C(eEEcB9PEmD~Cay&z-90=c?Fu*n2VB3wCvBM*E||-VivT0<+d8(7kXG
znAi!Kvs{{qa3~fBc)^$aMZ)^zkEb@SF3D)$G^N@E@-#H&Nz9LI`)v>rv3>OX2n78{OszZYA
zX^t9xIuKP&h#kfh?072vopRQz%GLr-0ZKVbufm(f%Hv$K2R;!^H^RH2TO4`CtucCr
zzctKa%cZYDS+LNwVC8ESV%6P?oI7I;eE&pDK^3zBGe#~px2+H8ce*p=%4SzUz$c&3
z89A|Fk-e6L_Vi)!yi%iBg08mCLxNk_7{k9CY5`HmdC!$+7^8`s1k3NDKWr
z642b}UtQG$=r0%YzulY=?q5lZC&r#T(-AviIbZJ_&9vaZbA7%|7w!3b1cCmkf<{ON
z&WfGNf^Gm9FiASAH1hQ(sBYR%E5uwSpOig{CG!oXKx@byfpf8(14|V79|M~+s8doL
z{jp^f^b=Z*v%BSTn1!5NrOK++lBAJ!mBMY-$bDHs*c9TP0Ed%Oh){Ii;BCHnoBi5L
zjWfuV?@KQXP=|kgx?dq<;>tc7mrZpXqfc`&;g%UM#{!#X%E8A?_+aH8WjVp!g7Y!|3=H7IFjdpO7ki(GdTDIkcE3Q;*X;^ip
zR=$v^gwiyo%Z%C<=v7g3EVmb!7@+zxq$|I1>&wYkNZC71yK3)r4&Qvz~mZv9csuOuDtXi$VnjxqsDh=lC62
zk&k?jW+5m4D`XZwzZ#vO`FOplH0dsS=Ov
zjkL*nzbWi@n)UK)mD6j_0&|w!0$4nrb~~Hx$R?(LQUMMQ#tG`96nz2DGnzRC79X1;
zuvw&2I^t`LpQk%q>Yb+>As~|a(@b_Zro@^sT6pqn)lWNj@OjaOU`c-c22LN8j0)O&$J}4iDX-`WVhz?UXGme7#8)e!X1hP
z9{>iUs%i!=;5PE0KpwPmT(fEK{adt13c^7*Kk7i@^leHG9OV^~wdqeLUr?U$TlKUE7YMbN@^i&pSO|MK4+0*2S$TIj17Y0LA?tsX0Q?
z5`nl!3!FT#yC%)zvtHQ?4&F$14cD61Ss-iZ`-c})O}G{tLLIJhDaRoknG5k+cNyeb
zYzjH;Y%@UR>3$Hg2vpkW@U3VX&FEzxREF?SjK0a|MW^%+L(zpkcI&qzQmY(h#{bE!
zV}KnJt@wP{@EdUq$TrUZPtRmGaeVht|G`x@mwnuOyU_Xc4WBBX#A!?C)_B)jF88{c
zGf7Hr$iTm;vfy?^8Oa_Z|8!Z7K-td40_7Z9SLT(2f`=3lg@pz}nwn#WSWXo{)qMC~
zp~tFmN=)9Rk-L5UcIZP}!`OLueV$=cxG~4j!jBzUKEL?m%f2vH@It#yl3ZMS=j$0e~D)2O@_qt|DDs9-RBH`
ziX*l_mt@)XP6=q0KERnprPFW)86(Rgh%?}Hks~0{!^$oLvg{(5YrOvM(H)WmVF0{t
z^K`O`x};iO+n|JGvbHf;(M>KIQdG_)5m7)eB?IGLz+8CWz;GQOgBSf5h;QzF{}w
zwUEtv2R^QO!%@+jeNF-TT_EWwy~@rdWF1-2dJqq__&ux1uMPO#Hw4BpLC<{zoB3iL
zru!3{+_651J-c3nL(HICFFS|f#@8oK=0sFlfU+6k;sx3W@BQa^==GDInaI|=;EM_b
zX9DU~S8~aaVWz)V5pNV77kGxTAHS|kC*_BT9?743p{V}w=jYC{jxI%KTZY1iNS@6M
zxAkTEb#S8=0`QESm!%mBhIjL6KON7tub+GvPa0qEmDjDyHMA*kq54?)=M*34d*hIO
ztq?Hb1^b1osCJ;GUXk5QUc^zIS@5cwmvPPMTkv}=M`sAG8VBd62d&;Gm{k|fh3Iz5
zXs0dp;+87$g~xL$PL?|B8Ny!!K3S$ijq$i=?O4TjtYLfL>KoxY1^;c|KFQ6by_4|i
zB>}zz1r-MiihKB8nIBJ{Pj@K8=03d0sXL0HOk$2=$xi&7Ls6Q5pVLo4a0o-v-@Wpq^r^a5qL-{
z;ysM*of2(QEIr)$Xy!^!mvbvTB|9hkt__`bT(TIcReVMu$Xb_#ix&?r*b_+ChmT9g
zx()uI@jF89>}N~7U;kMCaO89>_I4~VYh3euhJc7#B{_B8T1Vdefk8hhAhR5w-z^tsk_*xo==Bp$Ej6FprFEF%cyhmwb{-B}1sze>Fjo-R|
z87?R3c0a&BvW-Ed?dGjZuZI{b6tvE;xx=%!Td5lrxPM==1QB#(Szw%x0Uw1ku(jD&!sv`PsGD58XP3^5YY-OQ*A(xTEJ42ZNtNJ~i!AR!>#
zF{H%MLk)BG81MPs?>g7{i|Yb~y=Skz*0b()-@oTB-_|y4?wvf4id8sj7Mg#AI}H9Z
z{9h8QQhVmGx
z#z^ucmvYR;5PfQLDN>)6e@K&C_b3|DxM4@{A*JlrbvfwAsu97NrW8@kDI1{gFuYP5
z>j!^!M+>eMs0LEFan{DvZ3FvTf*Yqf1Ps4tI!Ujw<9iiT4`mK9@36Yj5rj(SAcpnALrS
zwAZd>@9H0zRq!j-PY8=D!
zvID2MlqT)^LE#5^gu}$SguJ%!GK
z=4>aiwQ+A4M1z@UV4buu36iWkRzrdCld$j^KScuAJV)l2+c%RTrZh
zz)cQji~h0MXYx3xkp4m+w+aEStBi~Fz&UAoTf*s1lo+Z<%^0&iuw!=Cmub>!zB{0B
zqX9EeK&r;xf6667!}_@#afP0p{+YRp4U)nHku5n=WRTApcnZR+1P*YSGa^>qTpUXq
z9S;|bh_fdZU{2#D=@gtW)0ba*uraY8
z;5#2RO6se5utftU5XxlbP2
zUJO`iyBc75_Nxp~FRHYCN#GRB|*NPdMS
zaxNV8x&TvwTyd?`YS6Z+rvKX7AnA#|QHAvLDDXbmT|TaX$k>51VbnCYH#+2b5Ui~~
zA~B6Y#+X<=Cg)>_Kce`{No>i{8*!=E$;Wd|OOiR>BAL6=-kuS?>+7_@+G0)4z_Cl}
z!MV-pw7AOO-03kje}3oU`5j^k2CgWmvPtIqed42FVW_C0&v?iYJS6jrHY7}@*gxTL
zmp7e``lJ3pg|dm{^TJ27{4GX>7c*P8>hAT*S<5VB33&^SDf2euMq~5JSUief003jwmrN(Vivta>Ho?++4*s<((
z_ItG?kqAlZ&!e3py1+r{oIjfaUjl}sqheBgz#oj=80hDHBA>rpTLZ?Nup-|p74|h4
zn-yI~irSWo^b(}oN5&fA6U(TDsHrFRl|hzfzivXPTb!rf1eH3LlgTXqq)*U7F%<_V
z3{rhMhF3tLV1|{Po|KrsG!!jbn^AjuWSLk``|~eTMI*Y;PjWQ^BGrh=9*Kv1_-bO=*%-DX_wa?*%Ixg7PibY1$n?veq7zg5B6T8n%`v*xbHX@Y2KiD+WJYA
z8ho^q7!k_3;0s3)w{rO@Fud`B&wWW4O+41nm-QF>q36yOD9=
zMLsMrLji2h_8Tsr-a7)z^&HMgpIPKzgEe&ZV%-p_&uL-S2C0Wnxe6*Wl2~F{`m~-?
zL=ES;UyL2S_8MNLP6N?i(WfdP?LT{p6|0e3i)CdD#hOWZI?>F`6eHiWvZmpfA7T7>
zUJ6afcEC3*ZE~f~{x}YtKZa6+D!s^WtVi5hS-B#txEr0a@y(=^U#>X*k=IAh$*Q!J
z43o_RVcg?-pNx_t8|{g*Zjbb=P8#)%N9Hx=b&qUo+l~*+^CL=2IfmW{M3=fD`{jHWFJF-WLah+#m+
zWKVW+d4QKNWa;^vWd)R8uo#=f4r{%288j?jMs^Ojeu&Wgts2)H6&zgvw4_+xk(~XF
z&8gZA0pbYPgDC!=6?dtHfjTM}cmSrprw$&cNAjCwfXAk?U{6Ns^V-O$e(Js?Q2O52
zGa4RWN<#C?#;)vW!B^is%&J?zocql~nPKtO)RT{j?PMR4D<&SDcUpB;W5}GUT`;Zv
zASYrtzF(WN;qmy4U>)WF@`S)i7ZagE4~oC+|LVImSZ;_CD7sG~Xz1eFZ1kY4Qkyg|
z8yaMw6F4K9)_cs24C3XFU>j=tlux^|oKf?cQ&}IdfEWi$nW!*VsJlDiRkLDd6&$`Z5Y`El-cY58J9e^K$whSF7Vw=rFD$%8$bA0
z{Q@h96!()VtLc$DhtcfUVFa02njjN@(Yt0_@y#M=ofo`EX?MitWQ1Rr3wVDiRFM9V0N{>y$d^-9lSb{
zZbx^p0iB9|5X%ZpW;KtkWV77hGyS!IIhEF
zutnozJJVyk?prAl>iiXw`o~5&jse3+|F3^oYpncAAeAsging0aY1z|#?nbxHx~fp2
znolBtirccCQFzZ$1W<9)s^ruG6}Nok?4${8(2F*}ysB?=WQRQm;XUu4P)?UyM;@Ys
z#uIaYRa>KvjOO*{?4PTCU-cBs!OqZ^eGT!A{((r>390h*{uu)@%et(h>n5CbX+1pN
zUAw-qedBmQTuR+2Yi;PUL*f2+_>=|zfY$1IpZufWVip`ojT0jMVYg;JAyuf?f4Zq^
zQrio<{^Y;?mPO?wAh&XxNaS=&b9SC5~%v)n~30F0s1R=ZKBZM+Vp=-8pw
z(_ef~hT6}cgp&*TpIuGv`#LF=>N04%8(jhlKN^bZ!yI1m4$ltcO8bE)T>hnl*!E&5
z@(nCpiA|cXdz;!IPiefuw)haOsldTLxMp>em;u?3J|8~lJQs4D!mkJAiXAT~Ya*|I
zUN5I+kJhsPig*-i%k;UN*ktQ8Ic;#4RAtmgIm)meb`kktK&^x%^`8`ZC1UGv8@+R>
z%_obqTO==2a-yJ*Af85%Qyp+Q2LN^w$$^UTn0reYl)vTCeEXA2j~@ry_h@N!uO5`X5KjA$_QGahS%Z^7
zro7wgVRnzV;DEHFN%nBw1@E!?M+l!kDp0gb)Yjyk@{fZoM6!ItKqitcW{aV|XI>Fo
zUDTMZ7*p0qIC6RMztr0Wj@
z4om(~Lw+X+`IY!C(Ou4DrFP$qb-)5f63W#=MWhb)>?=Hw3S
zqIlW{)KpyEuw7H2S(7sZys2qTAU=~)VJ9CGZu>h8KqgAKwq}x)bo!W-+4Sh6XeXp3
zuYbkTS~jI(Wdy}VGZ$nob;HUGs#dfaQz>t49uixVSf?y&1;@ZfG$UXqB#nG$IG3R0
zLtgfQU3ijZsm7nYsIB~A?R?k%i9-32-u%@+fej6UZ&T8EQ?wa?A0Yf}j}J|u8D2cb
zLB|!to{0jw4%&^lJ3G+`8fxnmAj#9oburR^oRiu5{81qD2(m&2;-7arcjt87eVBoA
zfz^9-IQuZ&CdCCfM*SMG^@Fv-MYY(FV+p^ejGH(2sef}0yz<-!_GOCt1=gW)-(bGW
zjMj#QOYlEbkEfLpw}5bOGw?kF8j8T#bf!pbByIY%TX%!;Rq0-r5!IgEwat;$VaEE+
zTqVyH1EAd*Q%eMi)@r
zA4So=M*qw0Zz--=#9dcQ=L2at=m3697IAf2d$&7>lc6F)pT%a9=?{CkzSjj=V0xae(Z;Rou}jlK1g
z04fU*$n(C}4DmtW*(y0mRrEfKc+v+$Khv*PsWGFVtw`F2Gc(OFSnotdg=vl-{1N(s
zy~gF|e#uL#ixlf>wzZoi9bO7`z{JeVv9tcdAc_ik7vV7_IS)DmA0MGkz(}e3g!U7y
ztPp+$L8R)xA!IGf4$JlHAI_1yAbZEe*tpgFtLMWylPfP`Q01x-yiTQB@!O{Mp0V
z)KtCm;5uLJz^5*pVp6r`PkeeZ4go9Rbmi;nLmlf@{wXNyCAmq@+jNCRk=;FG(tF5tbnNQBJTkSrV4&{
zbaeljy$y$$cop;N)$|C{Yl!G_2|MWOD14Y3?PaXIdG$kB)Z-s2R^Qj0oT1u|QZ>`3
zO3hDLVKtT~Iobuu>4--u$-HZ34c88`GK-A;tCEv`;_`~}->yz)J{*fFuya><-^KfW
zLUO``YC_z6Bz{Q~QzNQlWX_t*GKguRp7gwTT7_7TpZshvBt4Gkn
z;Z`8Ot;3xxCN(aPva*lWQZAF%)z_6UFZil|{rdIb=~D=|A0~Y7fLi5JsG7=4ukwmd
z-FyBLV~w9sC~yya
zxqXX?GGIi2;a|$ywv(j)!Mf3Q7*Sk6VSfo$l6+_}`%8pZgF#`x0dCl!6?Tf1V4QD=
z(a(ATB<^I{IgF#v=Gdge)XcN&d^px>Tjd*I{z>qhk*M9t;BJ
z&;Of*2b_A%j9i|g>RrIl(lYP5d2j>NH!0T*j08GjxN{UBU8Hib=Cs`q+wH2
zz#WBVDM?pkhGc}7z%h~EG4D$^Uy_vuZm9LS*B^hl4+Kjk?fsL04=uQDQa{nz;YT34
z^0L|5PFHkBP;|ooe2^TDqRpo92BqCtEob8Z_;zh9H1oGIVp$_XU*xt0`c|!mpUK)8HeB3RouDtukab?4ciL6n77%e;!
z)Xf?JN~9*eVm185R>>HWxa)Cq;#jKi^ToY#cI@D~uj-Utdf(m`GMgAmWc?J$`ESeJ
zMLH#zmd(ZMdx!!sxmFn~AqE2Das^ULs=qyETR(N+3Jj-vLd;SA&_^?2Gs
z|6}Cg9bLcd!)T2
z%wDUJTETVT{I-vRub7xZBaPn%wLI_7u_4+q!#fOjs%zxMK$tMk@`?u^TwQ%7tV4^Y
zS;y+!loz_kHajNQ9e2*OZ?0wSXGUr}*~oXh+!4Q=Iaai)IT-h}WJfdTk?HTb$?L<9
zHa6BpkC=nC+p(6l_@{(NLMC}FGu;n9Zx*#9=8Kw%aFX94I&b{if00(6P;lX6dch*>
z&j7GeoYFFWtV`yoUKjKJ`4M0oWX@!-|6aYVSY@4aHNV+{KDDWQR-&4#jSFgP>@VEj
zgKu%)4BH!Z4p2MBin%Pp){0xjV@m4&gY#R=R1TdEKg>9<`9lNBC3Q>H(70OkRmzH_}_pO*hN)`V`h#@a|brY
zRx25S7rmQLB(Hdp{^T@p?oDqZ((=PSpHqc8h4-dyqv~rm5H5&)(t!Z%=xbN>+gpE4
zTniu63~gat=^|fd!T?L&c?i6CWk~=2iq97S@0E3?zgV}Q-~;nP00eMLz%LlJ^)dh~
zI2{BMRf@X3GbJ>hB0*fldgNl|@6UFfk>qXe$gq7QulIRD1HI?Di?B@#nXf(%*MW%a
zRLmPGr=HLqh~7a!q{T;)TrB?mVP@`=a32UzcCU4{rk<%%g)w{;Rcalr+c`Tot+q~m
zJz=?`&H#L!)L7ms#945APXSkO=pI8`X`YRCSB-(H29ExtG(CP26wOiq5zSAVe`q3T
z0h>x8e?vXp!{zwv@h1SJ8`8lgp}tjkQf^bppZIwur99`s!cwk`=UtNK1hvC|6%l$y
zo*Q#@(Qb#VYI8V6c!#vd*4eSdQfp_`H1%=H_mR{O$uSzeLihch(!m}<6+Ht3EH+L^
zuur{mO0Gftsdsmeka{{|J90GV`$@~1Am!03rgf-9E94z&;f;pIDz+qthkxXdxE5qn
zY-7X38NRR{57=h%$3aF(AHutVk8+2!ar=B1F=xD5d9NYqKj5Vx^OsP`p>({etkzSi42
zrRx)GqZHU?U%-#Lb=d-7J}`&zSSObbo*L?W=N6KDlQ{+c@+2kmrs~F3lLu$wHpiDF
zD@(KWKi{pPXwzYSnNpsO)7Vt|c}jX$sb1S1pj0^ht7cTguZow}EpE$duo72J)+Mxf
z18dFGm7OlOH(Hv&IW|1$3tJE;klGGeG2-E3uq!Fh)SV^&a5@SaH5fyW*wYtuJ+cN?
zT>=9@4RPpPSoxY#;EKV_&FKxJrI@qD^V`L@GYXp6f-WEhUus)k%4()O(l=1uzdEU(
zc^#O~_IpvKw#hpU|K`y^n!5|)s>~8Rhw&y2oJ&@57V?7@Jpbc`3KW@So{N_*k31i^
zX~rg6+G8eZWg?}^H2C5wuWOB^Ldm2}dx8t3=BOvs^3Dr)U@67%>3$X(*kCL;br1f{
z$>VO-O&YyEAACO`PO(^Q?0q5K`mc35BI!Elz0Wky3hN?*8YqATHIqUfTQjCox|;7-
zn!g$%k-AqJzUo(+jqP6Z`@S#!JGc{S5Y}0`Xe}(gz6`I}
zzF83o5x3%-S&(EQ;)8ix=yp>OsNz?+Bwp)hITt>vlC*7bGYKv7I$C@^vkcz+jhP{n
z%qQVc%hYlYr@f^23XA{dU3%Op9Z~aH#qpNGqMqO`&J_X|PKIu(wjga7zT?{xrUw)j
zK;9LD;mHkZ{rEf%Q3Q?hwE1tAllfU9xX58C(n&BL&s<3NDBfI;a9>LmL6``j#fvpT-|WK4th?#_1#Fqj#_8o7U%kf*BKL
z^40m9J{`>iIG%tRo~4})1)N{041Vr;>52UGP5lRAdSKLD1@q4ms^;=kXqxoRWJV$Z
zArn&Nqp2Wqt8=?#Mo;o*@QvWo
zkA37g&g5K1+(z%s$g`REQbfs&PTK^GmsCIoqVt;e@J6J=1(UXSr?1Noq+4s8_E^lj
zb-B$*yVVB1@-=VjqW0?*%ZB1Xh$I^75=1o~efyu{*?dhkPxEF|c3dOFQKwUZdY>45
zgsV{ebyo+tB@sEZI&B1vkSfOMDBbrKpnXEHJZv*tbzU
zJwY=Rf&iX*>?iiKIV0wc7B$csfL^N8jMhI|ivS|~I}&u^cUnos_2Ae>4mqi6c6FKz
zRc3vyD^N_2@l#JV#O-=?Qc(O8NRY;9GR64MGUQEMfEFLQo^TxRi;uEZda#OWK~>*n
zhgNg|jXn^FL7w1~*wQWvnbjZsCtBNmL$w;kuk;90JE-7MJY4jeRVs33)cxUU>nr{y
zhlA%70ONk;n&KC@2^aJ%8#hnObsD%%yKQN`c>_Ze!)zJQn~O?(6eYMmdklMKS?C)j
z5_V$cRdL3tUnHs|^0#})w}?Kr%-e&afPD7q#QBKva!=!JgzLt(4*Z))
zjH|XmB)21srDJ)m)DMajVi{0I0fAfF#4=&b_1=<}N`4ep+%7#cRSf_PfM<^z=a}#s
zrv&)Y)^|;)PGHR>eq&^a>CfRsjw6F*Jd##};TB*swnxpoq@XD02AY{q0Cv
zXckJ9PP>Dk6S2;bonW*)umi#$wqh7}%`K4L-zE8q%YSImE5@fm*~WPeL2
zbuKQ7MVGeCDcV99E~>=Dr_86+dNwJm*hV@+-N+2w*2;*uhO#N-m2H4zZ*jJEBX3@7
z)(+xkzDQP#;kOCEnFq*1`J^7pXb%ORhWtk`uP&zLm_VaIo`@2^tZ4`SyC$uO$Jgk9
zeit(&lc1PucQ_jcF?dBF%W5RE9lw4urKv>{3~u@!Ex
z9AY@l2ZZ)pcATss+}BRGd(Alx2;F4XF)%E#6@jt&UUJFS29lE*Un&=H5LPpw7)_%z
z{5}HR9-|gTiz;WoPtk0eNhip*RpT
q#N
zM3V3LViWiZn!@VbfLu(Vx*)6mbk^42(up8Q?U1}vP7(s01xtx;EzN)!mAm_hF_1f7
z4uI`z3YZ4Ktt8sy`nRJrCcf%+{jm0=)(Ct2q$e_3^GEn&o~nxXmbFRgDLNj@S(7!y
z1Fwb{6P`J9aJ+Ws^D>CXuNs{%bMt
zsLTBFvvUK8A_iL-)Qj)D60a9a8mD{S>z+}9Kh31!|Vi#njs4tR)^;}i4W`<&&!Yrx_E_$gVD+~Fie
z8VM;;NGHjj*la>1pd1#-Jtlx}89ZJpJ);zbZ7CXB$r@s-tWYliJ;cPNUe7Tb3`t;3
z;DW#1=UyYR%*T1JdkuJhSBvV4;whcX*bP~d`SR?&f8vQj*PDY(5;%2#j%>CZE{hYIdzMG4s7A)u!xtffnRLWB)SPW
z?k?ge+V{7bNi5Ud7*ZXQsEY#nGbKDmW}rQKR=)UTmpX&>Jt72yfZ8Nt8~AMA0^_4Y
zOurLp(sSA-;3+hNCb2Pw<}3n)lx9*8{LVaoy;@9Eq~Fc@-kJTkqvqFqV@J0-K95!+
zhpdujO8jC*D@a&dO9+0=Bj8mE4J>E5kxe3xUA*HXaMg8pYnUHTb7`j@1W2>=1Lq`U
z*}}{&f#7}@BAk4mJy}2eP9{3b-_#bwW@UKhfQ=4QBm0#VJZ_8P~I(&
z00IShzkM9N!r^3DPYWv>f`Jtw0ipdh`r^4%#oKq$CN1T)Am&h->XUa4?3@tz5wE=}
z$HVdLvnyjp2+3t!*mtzJsyhM6dsTKnY;>$0K}Y0-6cy!bp{|?Vu+n;!=>J~2`jcf%
zV_;Ju>YP<5a7;`7$c`PJd;tH(YSb0k|38oql6P_JsrWH)?Ih_c$-ifz)CKa3eIGz(&CV!T$8Ci8;iNbKW
zxi^WCl1@NBg`ksHhMtbPlm*GBJc?+iQZ7esJoo`0O$Z^Vl)-VmqJuJ<%+}@BwFk-xL
zu|G5XvfkJ{?H}VjTZV4N&tGA<+h&alL>?|T9<%^<$ukhWJSoNA^=p{^)H~IKu+9dZ
z6sdK(n0+XoKgfbb&(0MT7K*@?A6og-$m;}rYv>fIu5_;5klGHUDPjwxN#F&(UWT!F
zxk6O9ug!Xx->eb_UD`>*l1xnISN@cRd@BxYBYnsWtSy??dF%*m=W~e@>#ZuHFR-)}
zo{&(&lENs^n<8&aQ|tUIEJ^#-k!~=6QlcX)mTNBe8P6oX9&2W?MN`c;iL-$iT;9)8
z9X=eCT}TKHweYGxlQ_S1WfkEJ4fd7xCar_A)O+>9B6yQUZ|6)6`r#ywdk)%LZ7Eb=
zF|!OHK6ty>)597xb0;SDzSiBkeY2qkJY@V?z0n{Z{1`h~HPBG8bdonM1Pd^z2U3o>
z?^8mJ^`)w^#wqC&$Ew?4h3Ky%3OA|7D}QxJKQ@tR-OcR>P)rn2g%?9LdaN
zt4}$?j?54DK8+s47SjSmnfIVP0HA+Zhkmq8A6!Uk_Sy$m>noxH{5v~li~_{`CKao9
z7=9UqYn(T`VaNWe>u5y;pL&QmM7GQ$>gUW`V=by9Xg&}QjXJ6L$|`yEOqq`|OTooi
z{Dt528wy?pJ6JMla4x@xpQeiI++*riPo&9iRQ)s?wV@z;b58h9#2M>k4ig^1>
zaUvf@>TKb%#98jibd%c{k9Wf-bf&V
z{MIu`{+(r1U(BzAnJ>lqZL+PDL-D{dnhleL3P2SnUOO+i?2L&74TVm2ZTjlgbs5O}
zryXJ%(E;<}%>c8i?kDeq=VkZ|@4-fw8J_J#{(Y$E?c03p*!C>77=Y={ZS<1e<{bUC
zZrPH_(2Vn#+OC#cGiH|uzR8}eXMc5R_uPUqa2zDeOYoyOT-;UB=K|oyi#JsPbe9t@
zR6mp}*1vA*={N?xw5D)#`t-x|ThxV%liG>w0-i@Jy8aG2vqhncr(*gb(b*xbWAl9j}HpurX;xa)&@s(Cx@xf8E{T$BOr&>j-J2*(H{yV$FgH63c&YItC
zoLoT{QtL*MjUj>OP6p0K+goc#@bM=V@yBK6yJhnP8qP)RE*82a
zybWwer~yVmx+}zgNwH$`)HN}*rW%7EoJnKy@I%jdMFO@s@)s17o**$R8p$CsnY0=I$^6}Veoj4ThD7Lx;drh_B5
zD|;q`j{knraPsl5`D*?WHnW0r!iFlt;~z&XXG)efD%$p$Lirb{lnRWP=%rm;9dehb
z4yd0`TR24WS2kGIr%$kypZ+SyrWH&;#{-%&4qf+t{u{<){NT!XPG)1Hx$NNr?|vfE
zy#{YfxSzw!Xb__~^|y+3{DADasnCoj*>f$&0E6J|b-*9V%ymDSIZZ0|=fyPD+6bCz
zKR9W&Vs*{v*iFR|!(!1p3mX-Z*#aV%4a-Nus}#cHC|9{uQ3|Smgy;7F;rV$n&S$%m
zYhmARJweSn&p0OH9bEsFwTlAYM;x*eB3gXy<3=QR*DB8{cV
z87EcKizjmxu*NezCzaL9f@=(1>(hlnDE*HjS{L`pFYZwFjK1hnTn8NJuGr=u4U~e*
zk|2v3_T1BSA{Pb>6Ibg#egf35|N7JIqb!+G%JfQG*0(EVf03vi}T;o5FGmZIs0TkC!m
z6gtSS^IimuDa^@z!=EM`8!Qn$()W*SrO!ayVF1)Z`P>afbt2$bIf^P_|H-XDH=AvA
z`(pGI&|;9fmh+<4Yc0w@$l?DLssk4dTpywRg?pjn;M|uqN${3XQ2@cbkyUKg1iwyP
zOuF?wuUsg|hC~&`bRyB=E%P^#XM%bDCqe;vZ>~hVg{SuS@3HJO1(TpaG6~b@?v9SIpzK+uP%9!y?C`MuwgqOoex9%qVwaFE
z)VV&_RxdK&K%Gs@@=J2q)DiG9`j-E*pRij3)M$>^K=YcWXtNvDFqprbKZqB75WCQ82YuIgfL*PX=M9=FLl&Hji%^rd@dP}bJoN%BbAt`+%9
zl6){G&|JFhwrwZ3T!qku&)GOSYMk=0Mou{H+MBVkcyb@7q{OS)Ad>q}>)Zlx=lM#<
z6BxIzo2VphKwspg;rsft=2=-Q+F9wI)X@XH9|G&L^KBoBl+1{#m2_>xE8R7Ykv=IE
zwoGh{P4Dbal;#yV>X?GZ=1vKJ>Lds231M>gE}WX)xKd;}c${HKFYO59(&1=R|;wxo>~l
zEwb+ygUElsiySu|1DryoFP1=Kwt3pF!m3Vzr#DD}28evJ#gLb6fZtFUR8jzGb>Uc5z@w#c}^wr^f(R0FPq{1e)Lg=Q|AT
zF`yV`F8F7*qX-`|7++tDH&@HMsp8ebFKBz)OvZoC}!Vcwy1WKPCO`zC18%ioNq~3
zjr6<1-^e8Jzdtui%CKMAZPqM3LSn24-88DEfWt$+1fiND%?Ee>9%!Ov*nju`fCTbJ
zsgeG2LRO5b^6_x9PD3ZkgR&*sd0RnpGlKGbB$aO>KxvVv${*$n{G
zM>4&`xUB^TTJ0@T5-yj9?!^ZXT$M@e?t=%=YP57rBr!3v)@OZ`!+RYd3!ij4RfSv1
zb6B>z(BJs$tzG_&5d*lwH%Z8+MphuXCMeMO9nNWr#-vOGb3h!{ukyNS5%o4s9KcoD
z)AUOJQDv=xx8w_@bj;S#$On4Z2-BWF(1GDFR^g*$KMDJc5W8uO)4fyi<+~^%zT4vJ
z^-VxWJ=b;~!9l2K%-cAk-{a}Qx!-6uZulpUI&6*A*!#6(F#Q^oRwv@`Y6v`AomZ|B
zWJ)_gV@-mo_Av^W^10ebIo@?FEPOI7ZArHx{SNvwI3NF@R*Fr_yvhQPljkva@%xd^
z8Y%AQ+kxuh-PqW$65c#}7FjzJCHmf-XT>A@uTyEVj56=@XL?`>aMuedD=V8XEG$G_
z`NCdaZa0%wM85m0Y@kq$DNm&M-K^OyCAqC%+L!Lh$?x?k&*T0ypc@!~06j6^Z#+;!
z4VN*e8$4Y%dJUv9w|OBdx8}8E%N|9S_%Q0;Bl=ekH=VH98w5ZNlNyjm@{yGyB!6Rb-j1`E=vui
ze07OpuRLMbHAc98F%utAgq^v<@Pq$itX_ghZ
zE4pm4W12ss&&2hnW)rFFJjFkp_(L;
zaS^*YCD2e?Ya&a=tMx=UTZ&!i?^s(Q^gJs#=W7M5(MrwVvSQ@<*^z?vaX>rSFmS1}
zAcnui5y*gGP6(`9`TB!#2h
E0Km;Evj6}9
literal 0
HcmV?d00001
diff --git a/src/en/space-station-14/departments/service/proposals/joker_roles.md b/src/en/space-station-14/departments/service/proposals/joker_roles.md
new file mode 100644
index 000000000..77fd4ae9c
--- /dev/null
+++ b/src/en/space-station-14/departments/service/proposals/joker_roles.md
@@ -0,0 +1,84 @@
+# Joker Roles
+
+| Designers | Implemented | GitHub Links |
+|---|---|---|
+| mith | :information_source: Open PR | TBD |
+
+
+## Overview
+
+The core idea is adding a diverse selection of low-stakes roleplay-inclined gimmick jobs. At roundstart 1-2 (map dependent), will be randomly selected from the larger pool, will have a room bespoke to the job appear in a pre-established 'template room' on the station, and will become available for players to take.
+
+## Background
+
+Gimmick jobs are a pretty common thing in Space Man Games; various servers in ss13 have barbers, boxers, clerks, journalists, psychiatrists. In my opinion and experience these jobs are divisive; there's often a handful of people who enjoy them sometimes, and a much larger contingent of people who point out that the roles are dumb, often completely unintegrated into the larger mechanical ecosystem and amount to little more than a greyshirt in a costume.
+
+I think the key is novelty; these jobs are often fun to play or interact with once or twice, but quickly lose their luster. This proposal is intended to allow for the kinds of fun roles people want to play one time, but probably wouldn't play every round as, without creating role bloat or half-baked jobs that people just use as assistant+. This would also be a good, low-stakes way to trial new roles, or put in roles that are kinda stupid conceptually.
+
+## Details
+
+![lil_room.png](../../../../assets/images/jokerroles/lil_room.png)
+
+These little rooms right here, the kind that you have in hallways, often near arrivals, would be the mechanical basis of the implementation. Similarly to how tg13's holodeck works, the idea would be to, on roundstart, swap out the contents of the room with one of a number of pre-designed prefabs. The walls should also be included in the prefab, as this way windows, counters etc can be added or removed. If joker roles are disabled by config, or for some reason don't spawn, the room should default to a standard Vacant Office layout. I'd like to specify that I do like these rooms, and dont think this should replace all of them - maybe we could make a few more scattered about.
+
+The rooms in question would be unique to the job. I'll include a list of joker roles I think we should have below, but some simple examines might be a veteranarian would have a simple surgery, some basic meds, some animal boxes and maybe a defib locker; a private investigator might have a desk with a bottle of whiskey, some glasses, a wardrobe with a couple outfits and forensic equipment, file cabinets, and detective-carpeting; a store clerk could have a shutterable windoor counter, sellable stock, a locker with some cash. In this way, each role would have their own slice of the station, with access to equipment they would be able to use in a way that feels integrated and intentional.
+
+I can see two ways this could work across maps; firstly, the lower effort method, would be to have standard map-agnostic room templates with a matching footprint - all the mapper would need to do is ensure that the room matches the 'joker room' dimensions - say 6x4 or smth - and mark the room out somehow, and it would load the same room contents for each type of room across whichever station it's on. This would be low-maintenence and scalable, wouldn't ask much compromise from the mappers, and would (presumably) be simpler to implement.
+
+The second implementation would be that a station mapper can opt to make a joker room template distinct from the default footprint, and would then create a bespoke version of each of the job-rooms that would fit into that template specifically. This would allow for more variety and freedom, with any given joker role having a few different room styles across different stations, but this could also work alongside the simpler method as a default.
+
+In terms of job selection, this would work similarly to how station-dependent jobs work right now; players can access the full list of joker roles in the job preference menu, specify their interest in the role, at roundstart the jokers would be picked prior to job assignment, and the jobs would be entered into the selection process as normal, using a spawn point within the room. If a role goes untaken in the initial assignment, it'll be available on the join menu. The jobs will include their own access level - if possible, this access would be dynamic; only appearing on the HoP console on rounds where the relevant job is selected, this will control access to any lockers and doors in the room.
+
+If mappers want to go Sicko Mode, template rooms could be placed in and around other departments with a selection of roles from the larger list they can select - for example psychiatrist, veterinarian or plastic surgeon rooms could spawn in or around medbay. If this were the case, I'd suggest limiting the numbers so if a role spawns in a department-specific position, a generic template would remain empty so as not to tip the scales.
+
+Most of these roles equipment could be designed from existing clothing and items; while in some cases it might be fun to add new items for them, it absolutely wouldn't require any item bloat and could add some more use for items that don't see much use currently.
+
+Seeing as some of the jobs are a little abstract, it would be good to include a *brief* flavour text on spawn to outline what the job is and, probably more importantly, what it isn't.
+
+## Examples
+
+Here's some ideas and brief concepts for some of the roles that I think would work well here.
+
+
+_Clerk_
+
+Room contains lockable storage for sellable goods of moderate utility, a safe, a desk with some basic paperwork supplies, and a front desk with a windoor and button-toggle shutters. Items in storage could be drawn from a random pool or fixed, but would be maint-loot tier; yellow gloves, syringes, crowbars, white medkits, toolbelts, plushes, nonlethal ammo. Intended playstyle would be trading and upselling until you're buying and selling items of genuine value with a safe full of spesos. Could spawn in pretty much any outfit, so long as it looks civillian.
+
+_Plastic Surgeon_
+
+Room would be a surgery with all the standard tools, and some basic meds. Anaesthetic tanks, medical records console, patient locker etc. This role would obviously only make sense when we've got newmed. Intended playstyle would be performing minor or stupid surgeries on-demand. Would spawn in some variant of the medical outfit, intended to distinguish the surgeon as private and independent from medbay at large.
+
+_Boxer_
+
+Locker room with a shower, seating, some bruise packs, change of shorts and gloves, sink with a mirror etc. In a larger joker template it could include a small boxing ring, but would be unfeasable if the room is as small as I'm picturing the defaults. Intended playstyle is the same as the current boxer really, would spawn in shorts and gloves.
+
+_Magician_
+
+Curtained room with cool carpets and lockers - might include a teleporting locker. Starts with a number of prank items, some chems for making smoke etc, magic wand, a small animal of some kind. Intended playstyle is basically a variant clown, putting on shows etc. Spawns with a top hat etc you know how a magician dresses.
+
+_Gambler_
+
+Carpeted room with some of those green tables, decent starting cash, dice, arcade machine maybe, small bar with drinks. Spawns in a hawaiian shirt with obnoxious sunglasses. Intended playstyle is gambling away that money obviously.
+
+_Private Investigator_
+
+Similar to detective office with different noir outfits and no gun. A desk with whiskey and glasses, CCTV monitor, forensic equipment, camera (when we get them), audio recorder, bureaucracy equipment, one of those emergency sec radios but not an earpiece, evidence bags etc. Intended playstyle is a second sleuth on the station, can be hired by crewmates or can simply try to do the detectives job for him, but critically is not a member of sec and isnt authorised to carry a gun or anything. Spawns in a suit maybe, something noir that isn't one of the detective's.
+
+_Journalist_
+
+This is basically already a thing on some maps; room with paper and desk, camera, outfits etc etc. You know how this one works.
+
+_Veterinarian_
+
+Stripped down doctors office with some bruise packs, ointment, and bottles of watered-down pills. A surgical table, some chairs for pet owners to sit in, animal boxes and wall defib. Intended playstyle being a doctor for animals. Spawns in something medbay-adjacent.
+
+_Centcomm Liason_
+
+Room is a fancy office with a wardrobe, nice desk, centcomm carpets, fax machine, camera console. Isn't a member of command and doesn't spawn with access, is there to monitor the station and report to centcomm, not to take command of the station unless it happens organically. Spawns in a centcomm outfit.
+
+_Psychiatrist_
+
+Room is a psych office. Again, this is a job we have currently that I think would benefit from not being a permanent fixture, but would function the same.
+
+
+Anyway that's all I got for now. I put it in service cos its mostly service roles.
\ No newline at end of file
From 4781222684ef6bd9c68286f9ce2649a5264938ea Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Sun, 9 Jun 2024 14:00:58 +0200
Subject: [PATCH 70/80] Updateserver command for poweractions
---
src/en/server-hosting/setting-up-redbot.md | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/en/server-hosting/setting-up-redbot.md b/src/en/server-hosting/setting-up-redbot.md
index 555653922..60bf5e0f7 100644
--- a/src/en/server-hosting/setting-up-redbot.md
+++ b/src/en/server-hosting/setting-up-redbot.md
@@ -87,6 +87,10 @@ Instruct the server to shutdown after the current round ends:
```[p]stopserver ```
+Tell watchdog to prepare to update a server:
+
+```[p]updateserver ```
+
### New round pinging & Ahelp relay
While it's not specificly a bot feature, I thought I might as well throw it in here since there's no other documentation on it and it's related to Discord.
1. Make a discord webhook in the channel you want the pings to arrive in. You can make one by clicking on the cogwheel in the channel > Integrations > Webhooks. Once done copy the URL
From 3370b63d6925aab595dfaa417eb0a526b6a03a86 Mon Sep 17 00:00:00 2001
From: Azzy
Date: Sun, 9 Jun 2024 19:32:06 -0500
Subject: [PATCH 71/80] Update design-principles.md | Fix typo (#238)
Fix typo
---
src/en/space-station-14/core-design/design-principles.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/en/space-station-14/core-design/design-principles.md b/src/en/space-station-14/core-design/design-principles.md
index 8f3f7060f..97efbafd5 100644
--- a/src/en/space-station-14/core-design/design-principles.md
+++ b/src/en/space-station-14/core-design/design-principles.md
@@ -3,7 +3,7 @@ This doc is actively under development and is not fully complete. Things may cha
```
# Design Principles
-Here we go into more detail about each of SS14's Core Desgin Pillars breaking them down further into design principles. Once again these are not hard requirements, but expect to recieve heavy scruitiny on your design if you aren't following these.
+Here we go into more detail about each of SS14's Core Design Pillars breaking them down further into design principles. Once again these are not hard requirements, but expect to recieve heavy scruitiny on your design if you aren't following these.
## Chaos
From 5c6d47721a17658643eedac888b7ad84dcfbd83c Mon Sep 17 00:00:00 2001
From: ArkiveDev <95712736+ArkiveDev@users.noreply.github.com>
Date: Wed, 12 Jun 2024 01:03:06 -0400
Subject: [PATCH 72/80] Typo fix in pull-request-guidelines.md (#239)
entires > entries
---
.../codebase-info/pull-request-guidelines.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/en/general-development/codebase-info/pull-request-guidelines.md b/src/en/general-development/codebase-info/pull-request-guidelines.md
index dca4b9c23..adfcc46df 100644
--- a/src/en/general-development/codebase-info/pull-request-guidelines.md
+++ b/src/en/general-development/codebase-info/pull-request-guidelines.md
@@ -79,7 +79,7 @@ The Github PR template contains the following changelog that you can use to form
By default, changes are credited to your Github username. If you would like your name to appear differently in-game, add a string on the same line as the `:cl:` with the name that you would like to use.
-Each entry is either an `add`, `remove`, `tweak`, or `fix`. There can be multiple entires in each category. These set the change log icon and do not show up in the change log text.
+Each entry is either an `add`, `remove`, `tweak`, or `fix`. There can be multiple entries in each category. These set the change log icon and do not show up in the change log text.
Maintainers may, at their discretion, add, modify, or remove a change log entry that you suggest.
From 7b6a0a0d7b9a4bc81a2e2e1f6b5a1260a9f3bd23 Mon Sep 17 00:00:00 2001
From: Kara
Date: Thu, 13 Jun 2024 18:26:14 -0700
Subject: [PATCH 73/80] workgroup myself
---
src/en/general-development/work-groups.md | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/en/general-development/work-groups.md b/src/en/general-development/work-groups.md
index f2a846d9d..272d62e42 100644
--- a/src/en/general-development/work-groups.md
+++ b/src/en/general-development/work-groups.md
@@ -15,23 +15,23 @@ Each work group is responsible for maintaining corresponding design and pr guide
| [Admin Tooling](../space-station-14/admin-tools.md) | Jezithyr, Chief-Engineer, Vasilis, Julian, Bhijn & Myr(deathride58) |
| [Art](../space-station-14/art.md) | EmoGarbage, Flareguy |
| [Character/Species](../space-station-14/characters-species.md) | Jezithyr, Lank, Vasilis, KeronSHB, Bhijn & Myr(deathride58), AJCM |
-| [Combat](../space-station-14/combat.md) | Jezithyr, EmoGarbage, AJCM, KeronSHB, Bhijn & Myr(deathride58) |
-| [Player Interaction](../space-station-14/player-interaction.md) | |
+| [Combat](../space-station-14/combat.md) | Jezithyr, EmoGarbage, AJCM, KeronSHB, Bhijn & Myr(deathride58), mirrorcult |
+| [Player Interaction](../space-station-14/player-interaction.md) | mirrorcult |
| [Mapping](../space-station-14/mapping.md) | Emisse |
-| [Roleplay/Lore](../space-station-14/roleplay-lore.md) | Lank, KeronSHB, Vasilis |
-| [Round Flow](../space-station-14/round-flow.md) | Jezithyr, EmoGarbage, Tayrthan, KeronSHB, Bhijn & Myr(deathride58), AJCM |
+| [Roleplay/Lore](../space-station-14/roleplay-lore.md) | Lank, KeronSHB, Vasilis, mirrorcult |
+| [Round Flow](../space-station-14/round-flow.md) | Jezithyr, EmoGarbage, Tayrthan, KeronSHB, Bhijn & Myr(deathride58), AJCM, mirrorcult |
| [User Interface](../space-station-14/user-interface.md) | Jezithyr, EmoGarbage, AJCM, Julian, Bhijn & Myr(deathride58) |
### Departments
| Group | Members |
|-------|---------|
-| [Atmos](../space-station-14/departments/atmos.md) | Jezithyr, KeronSHB, notafet(Partmedia) |
-| [Cargo/Salvage](../space-station-14/departments/cargo-salvage.md) | |
-| [Command](../space-station-14/departments/command.md) | KeronSHB, EmoGarbage, Vasilis |
-| [Engineering](../space-station-14/departments/engineering.md) | Jezithyr, Julian, AJCM, KeronSHB |
+| [Atmos](../space-station-14/departments/atmos.md) | Jezithyr, KeronSHB, notafet(Partmedia), mirrorcult |
+| [Cargo/Salvage](../space-station-14/departments/cargo-salvage.md) | mirrorcult |
+| [Command](../space-station-14/departments/command.md) | KeronSHB, EmoGarbage, Vasilis, mirrorcult |
+| [Engineering](../space-station-14/departments/engineering.md) | Jezithyr, Julian, AJCM, KeronSHB, mirrorcult |
| [Medical](../space-station-14/departments/medical.md) | Jezithyr, Vasilis, AJCM |
-| [Science](../space-station-14/departments/science.md) | Jezithyr, EmoGarbage, AJCM, Tayrtahn |
-| [Security](../space-station-14/departments/security.md) | Lank(LankLTE), KeronSHB |
+| [Science](../space-station-14/departments/science.md) | Jezithyr, EmoGarbage, AJCM, Tayrtahn, mirrorcult |
+| [Security](../space-station-14/departments/security.md) | Lank(LankLTE), KeronSHB, mirrorcult |
| [Service](../space-station-14/departments/service.md) | AJCM, Tayrtahn, notafet(Partmedia) |
## For maintainers:
From 95f3b5bb0c413e127d6d4697286876db4c31fdf0 Mon Sep 17 00:00:00 2001
From: Pieter-Jan Briers
Date: Fri, 14 Jun 2024 11:47:20 +0200
Subject: [PATCH 74/80] Workgroup myself too
---
src/en/general-development/work-groups.md | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/en/general-development/work-groups.md b/src/en/general-development/work-groups.md
index 272d62e42..366fc5b3b 100644
--- a/src/en/general-development/work-groups.md
+++ b/src/en/general-development/work-groups.md
@@ -11,25 +11,25 @@ Each work group is responsible for maintaining corresponding design and pr guide
| Group | Members |
|-------|---------|
-| [Accessibility](../space-station-14/accessibility.md) | Bhijn & Myr(deathride58), AJCM |
-| [Admin Tooling](../space-station-14/admin-tools.md) | Jezithyr, Chief-Engineer, Vasilis, Julian, Bhijn & Myr(deathride58) |
+| [Accessibility](../space-station-14/accessibility.md) | Bhijn & Myr(deathride58), AJCM, PJB |
+| [Admin Tooling](../space-station-14/admin-tools.md) | Jezithyr, Chief-Engineer, Vasilis, Julian, Bhijn & Myr(deathride58), PJB |
| [Art](../space-station-14/art.md) | EmoGarbage, Flareguy |
| [Character/Species](../space-station-14/characters-species.md) | Jezithyr, Lank, Vasilis, KeronSHB, Bhijn & Myr(deathride58), AJCM |
| [Combat](../space-station-14/combat.md) | Jezithyr, EmoGarbage, AJCM, KeronSHB, Bhijn & Myr(deathride58), mirrorcult |
-| [Player Interaction](../space-station-14/player-interaction.md) | mirrorcult |
-| [Mapping](../space-station-14/mapping.md) | Emisse |
+| [Player Interaction](../space-station-14/player-interaction.md) | mirrorcult, PJB |
+| [Mapping](../space-station-14/mapping.md) | Emisse, PJB |
| [Roleplay/Lore](../space-station-14/roleplay-lore.md) | Lank, KeronSHB, Vasilis, mirrorcult |
| [Round Flow](../space-station-14/round-flow.md) | Jezithyr, EmoGarbage, Tayrthan, KeronSHB, Bhijn & Myr(deathride58), AJCM, mirrorcult |
-| [User Interface](../space-station-14/user-interface.md) | Jezithyr, EmoGarbage, AJCM, Julian, Bhijn & Myr(deathride58) |
+| [User Interface](../space-station-14/user-interface.md) | Jezithyr, EmoGarbage, AJCM, Julian, Bhijn & Myr(deathride58), PJB |
### Departments
| Group | Members |
|-------|---------|
-| [Atmos](../space-station-14/departments/atmos.md) | Jezithyr, KeronSHB, notafet(Partmedia), mirrorcult |
+| [Atmos](../space-station-14/departments/atmos.md) | Jezithyr, KeronSHB, notafet(Partmedia), mirrorcult, PJB |
| [Cargo/Salvage](../space-station-14/departments/cargo-salvage.md) | mirrorcult |
| [Command](../space-station-14/departments/command.md) | KeronSHB, EmoGarbage, Vasilis, mirrorcult |
-| [Engineering](../space-station-14/departments/engineering.md) | Jezithyr, Julian, AJCM, KeronSHB, mirrorcult |
-| [Medical](../space-station-14/departments/medical.md) | Jezithyr, Vasilis, AJCM |
+| [Engineering](../space-station-14/departments/engineering.md) | Jezithyr, Julian, AJCM, KeronSHB, mirrorcult, PJB |
+| [Medical](../space-station-14/departments/medical.md) | Jezithyr, Vasilis, AJCM, PJB |
| [Science](../space-station-14/departments/science.md) | Jezithyr, EmoGarbage, AJCM, Tayrtahn, mirrorcult |
| [Security](../space-station-14/departments/security.md) | Lank(LankLTE), KeronSHB, mirrorcult |
| [Service](../space-station-14/departments/service.md) | AJCM, Tayrtahn, notafet(Partmedia) |
From 04291181beef935a8434c0accbc455a422ae7e59 Mon Sep 17 00:00:00 2001
From: Nemanja <98561806+EmoGarbage404@users.noreply.github.com>
Date: Fri, 14 Jun 2024 21:38:21 -0400
Subject: [PATCH 75/80] Xenobiology (Mutant Lab) Proposal (#187)
---
src/SUMMARY.md | 3 +-
.../departments/science/proposals/xenobio.md | 113 ++++++++++++++++++
2 files changed, 115 insertions(+), 1 deletion(-)
create mode 100644 src/en/space-station-14/departments/science/proposals/xenobio.md
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 3e43b6380..265570210 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -229,7 +229,8 @@ Space Station 14
- [Proposals]()
- [XenoArch Redux (3MOArch)](en/space-station-14/departments/science/proposals/xenoarch-redux.md)
-
+ - [Xenobio](en/space-station-14/departments/science/proposals/xenobio.md)
+
- [Security](en/space-station-14/departments/security.md)
- [PR Guidelines](en/space-station-14/departments/security/guidelines.md)
diff --git a/src/en/space-station-14/departments/science/proposals/xenobio.md b/src/en/space-station-14/departments/science/proposals/xenobio.md
new file mode 100644
index 000000000..404ab572f
--- /dev/null
+++ b/src/en/space-station-14/departments/science/proposals/xenobio.md
@@ -0,0 +1,113 @@
+# Xenobiology (Mutant Lab)
+
+| Designers | Implemented | GitHub Links |
+|---------------|-------------|--------------|
+| EmoGarbage404 | :x: No | TBD |
+
+## Overview
+
+**Xenobiology** is a """new""" Science subdepartment.
+The subdepartment comes with no roles but instead a variety of machinery that allows scientists to harvest and fuse cell samples from various flora both on and off station.
+These splices can then be grown into living mutants, who must be contained, cared for, and grown until they can be dissected and studied in order to gain research.
+
+## Background
+
+Science's current methods for point generation consist entirely of just XenoArcheology and Anomalies.
+Both of these subdepartments have perfectly fine gameplay loops that integrate well with the game, but leave a gap in gameplay that serves to be filled.
+
+XenoArch is very reliant on other departments for supplies and artifacts yet the threat of the artifacts is largely contained within science.
+Anomalies are the opposite: they require very little input from outside of science to generate points but create a large threat that exists entirely outside of the science department itself.
+
+This iteration of Xenobio serves to fill the gap between these two while also introducing some generally well liked thematic ideas--aliens and gene modification--in a way that integrates well with the current design of the science department.
+
+## Cell Collection
+
+Collecting cell samples from creatures across the station is the primary 'resource' of Xenobio.
+This concept takes loose inspiration from /tg/'s cytology.
+Scientists are equipped with a set **biopsy punches**, which are single use tools that deal a small amount of damage to the mob they're used on and produce a **biopsy sample**.
+
+Biopsy samples can then be taken to science, where the **Cellular Sequencer** can be used to add the sample into the **Cellular Database**.
+Cell samples from the database can be printed at the cost of biomatter (scaling with rarity of the cell sample).
+
+Not all cells are created equal, however.
+For the purpose of Xenobio, the part of cells that matter is their instability.
+This is essentially a scaling factor that affects the extent of mutations.
+
+Common creatures, like rats, dogs, or other on-station animals, have a low instability and will only have one or two mutations associated with the cells.
+More rare creatures, like space animals, have a higher instability which results in more mutations of more serious degrees.
+Even still, finding something exceptionally rare, like a blob or a xenomorph, can yield extremely unstable cells that can cause lots of mutations.
+
+This basically means that while you can have a basic set of cell samples from just looting animals from the station, any more exotic combinations will require collaboration with cargo, botany, or other jobs in order to get access to rarer creatures or the closely-guarded head pets (Ian makes a fine DNA source).
+
+## Cellular Fusion
+Once you've collected a reasonable stockpile of cell samples, you can use the **Cellular Fusion Chamber** to fuse cell samples.
+Cell fusion is a relatively simple procedure that mostly just involves selecting two distinct samples and fusing them.
+Fusing samples carries a small plasma cost as well as a failure chance.
+
+The chance to fail as well as the cost is dependent on a few factors:
+- The amount of times the current sample has already been spliced
+- The instability of the cells used (uses the higher value)
+- The difference in stability between two samples
+
+This sample can then be further fused with more samples, creating a more and more complex and unstable sample.
+One completely finished, the sample is loaded into a **Mutagenic Cell Injector** (MCI) and is ready to be used.
+
+This overall encourages people to try a variety of simple combinations and not tacking on endless small modifications to create super beasts.
+It can still theoretically be done, but it's much more resource intensive.
+
+## Mutant Creation
+Once you have acquired a loaded MCI, you're now ready to deliver your payload to your lucky test subject.
+
+By default, you'll be supplied with a box of monkey cubes and some N2O.
+Knock a monkey out, inject it with the MCI, and then stick it inside one of the various **Growing Vats** scattered inside of the xenobio lab.
+Once inside, you simply need to wait for the mutant to grow.
+When finished growing, use a plunger to pull it out.
+
+If you pull it out prematurely, you may simply get a regular monkey or (in an unfortunate case) just a pile of bloody slop and goo.
+If you leave it in too long, the mutant may wake up and become angry, destroying the vat as it escapes.
+
+Growing Vats must be stocked with a decent level of nutriment and saline in order to facilitate the mutation process.
+You'll need to monitor the levels and replenish it as they deplete.
+Failure to do so may lead to your mutant coming out dead.
+
+Whatever the case may be: you've now grown a mutant.
+Get it inside of a chamber and start experimenting.
+
+## Mutant Care and Growth
+You have a disgusting mutant in a cage: now what?
+
+Your main goal is to care for the mutant in order to help it grow.
+This requires satisfying certain conditions for it. Primarily:
+- Food: vegetables, meat, live animals, etc.
+- Temperature: Average, cold, warm, boiling
+- Pressure: Average, low, or high
+- Enrichment: Toys, playmates, prey, entertainment.
+
+When you satisfy these conditions, the mutant slowly grows.
+Making sure that these conditions stay constant is important, as mutants will react more strongly when they have a condition satisfied and then it goes away.
+
+But what happens when you don't satisfy these conditions?
+In short: bad things.
+Improper diet and environment may cause the mutant to weaken and slowly die, preventing you from researching it properly.
+Uncomfortable or unsatisfied mutants may additionally grow aggressive, lashing out at their cage and researchers.
+
+This may cause them to break out and escape their cages, at which point they may ravage all of science or even escape out into the station.
+Keeping them happy should (mostly) prevent this, however, so it's essential to do so.
+
+## Research
+Once a mutant has finished its growth, it's appearance will change and scientists will be able to conduct research.
+This is when points are generated.
+
+First, the scientists must figure out how to kill the mutant.
+Gassing the chamber with N2O is a smart bet but it may come down to lasers or even good ol' fashioned hand-to-hand combat.
+Whatever the case, it must be dead.
+
+The corpse can then be taken to a surgery bay, either in medical or a local one in science, and an autopsy can be performed.
+Once the autopsy is complete, a biopsy tool can be used to take a sample.
+While this sample cannot be fused or replicated like normal samples, adding it into the database will reward you with research.
+
+Research is awarded based on the growth of the creature as well as the number of fusions in the original sample.
+However, sequences with minimal variation compared to previous ones will be penalized and give reduced research.
+
+The goal is to encourage experimentation with different base cell combinations, pushing players to find lots of different creatures to experiment.
+This lends a huge cooperation and discovery factor to the subdepartment.
\ No newline at end of file
From da306968ad66d02d9ad7e6ed044d038d2c68c908 Mon Sep 17 00:00:00 2001
From: Jezithyr
Date: Fri, 14 Jun 2024 19:56:35 -0700
Subject: [PATCH 76/80] Update work-groups.md
---
src/en/general-development/work-groups.md | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/en/general-development/work-groups.md b/src/en/general-development/work-groups.md
index 366fc5b3b..826e1f09d 100644
--- a/src/en/general-development/work-groups.md
+++ b/src/en/general-development/work-groups.md
@@ -14,10 +14,10 @@ Each work group is responsible for maintaining corresponding design and pr guide
| [Accessibility](../space-station-14/accessibility.md) | Bhijn & Myr(deathride58), AJCM, PJB |
| [Admin Tooling](../space-station-14/admin-tools.md) | Jezithyr, Chief-Engineer, Vasilis, Julian, Bhijn & Myr(deathride58), PJB |
| [Art](../space-station-14/art.md) | EmoGarbage, Flareguy |
-| [Character/Species](../space-station-14/characters-species.md) | Jezithyr, Lank, Vasilis, KeronSHB, Bhijn & Myr(deathride58), AJCM |
+| [Character/Species](../space-station-14/characters-species.md) | Jezithyr, Lank, Vasilis, KeronSHB, Bhijn & Myr(deathride58), AJCM, Flareguy |
| [Combat](../space-station-14/combat.md) | Jezithyr, EmoGarbage, AJCM, KeronSHB, Bhijn & Myr(deathride58), mirrorcult |
| [Player Interaction](../space-station-14/player-interaction.md) | mirrorcult, PJB |
-| [Mapping](../space-station-14/mapping.md) | Emisse, PJB |
+| [Mapping](../space-station-14/mapping.md) | Emisse, PJB, Jezithyr |
| [Roleplay/Lore](../space-station-14/roleplay-lore.md) | Lank, KeronSHB, Vasilis, mirrorcult |
| [Round Flow](../space-station-14/round-flow.md) | Jezithyr, EmoGarbage, Tayrthan, KeronSHB, Bhijn & Myr(deathride58), AJCM, mirrorcult |
| [User Interface](../space-station-14/user-interface.md) | Jezithyr, EmoGarbage, AJCM, Julian, Bhijn & Myr(deathride58), PJB |
@@ -26,12 +26,12 @@ Each work group is responsible for maintaining corresponding design and pr guide
| Group | Members |
|-------|---------|
| [Atmos](../space-station-14/departments/atmos.md) | Jezithyr, KeronSHB, notafet(Partmedia), mirrorcult, PJB |
-| [Cargo/Salvage](../space-station-14/departments/cargo-salvage.md) | mirrorcult |
-| [Command](../space-station-14/departments/command.md) | KeronSHB, EmoGarbage, Vasilis, mirrorcult |
+| [Cargo/Salvage](../space-station-14/departments/cargo-salvage.md) | mirrorcult, Jezithyr |
+| [Command](../space-station-14/departments/command.md) | KeronSHB, EmoGarbage, Vasilis, mirrorcult, Flareguy |
| [Engineering](../space-station-14/departments/engineering.md) | Jezithyr, Julian, AJCM, KeronSHB, mirrorcult, PJB |
| [Medical](../space-station-14/departments/medical.md) | Jezithyr, Vasilis, AJCM, PJB |
| [Science](../space-station-14/departments/science.md) | Jezithyr, EmoGarbage, AJCM, Tayrtahn, mirrorcult |
-| [Security](../space-station-14/departments/security.md) | Lank(LankLTE), KeronSHB, mirrorcult |
+| [Security](../space-station-14/departments/security.md) | Lank(LankLTE), KeronSHB, mirrorcult, Flareguy |
| [Service](../space-station-14/departments/service.md) | AJCM, Tayrtahn, notafet(Partmedia) |
## For maintainers:
From 87d3c94589468b893044fc558e02f4f29d11b0dd Mon Sep 17 00:00:00 2001
From: Jezithyr
Date: Fri, 14 Jun 2024 20:02:19 -0700
Subject: [PATCH 77/80] Update work-groups.md
---
src/en/general-development/work-groups.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/en/general-development/work-groups.md b/src/en/general-development/work-groups.md
index 826e1f09d..1a1922512 100644
--- a/src/en/general-development/work-groups.md
+++ b/src/en/general-development/work-groups.md
@@ -11,7 +11,7 @@ Each work group is responsible for maintaining corresponding design and pr guide
| Group | Members |
|-------|---------|
-| [Accessibility](../space-station-14/accessibility.md) | Bhijn & Myr(deathride58), AJCM, PJB |
+| [Accessibility](../space-station-14/accessibility.md) | Bhijn & Myr(deathride58), PJB |
| [Admin Tooling](../space-station-14/admin-tools.md) | Jezithyr, Chief-Engineer, Vasilis, Julian, Bhijn & Myr(deathride58), PJB |
| [Art](../space-station-14/art.md) | EmoGarbage, Flareguy |
| [Character/Species](../space-station-14/characters-species.md) | Jezithyr, Lank, Vasilis, KeronSHB, Bhijn & Myr(deathride58), AJCM, Flareguy |
@@ -26,8 +26,8 @@ Each work group is responsible for maintaining corresponding design and pr guide
| Group | Members |
|-------|---------|
| [Atmos](../space-station-14/departments/atmos.md) | Jezithyr, KeronSHB, notafet(Partmedia), mirrorcult, PJB |
-| [Cargo/Salvage](../space-station-14/departments/cargo-salvage.md) | mirrorcult, Jezithyr |
-| [Command](../space-station-14/departments/command.md) | KeronSHB, EmoGarbage, Vasilis, mirrorcult, Flareguy |
+| [Cargo/Salvage](../space-station-14/departments/cargo-salvage.md) | AJCM, mirrorcult, Jezithyr |
+| [Command](../space-station-14/departments/command.md) | KeronSHB, EmoGarbage, Vasilis, mirrorcult, Flareguy, AJCM |
| [Engineering](../space-station-14/departments/engineering.md) | Jezithyr, Julian, AJCM, KeronSHB, mirrorcult, PJB |
| [Medical](../space-station-14/departments/medical.md) | Jezithyr, Vasilis, AJCM, PJB |
| [Science](../space-station-14/departments/science.md) | Jezithyr, EmoGarbage, AJCM, Tayrtahn, mirrorcult |
From 1da2e7c5155422aea1a66249e90fa117e9ebcf15 Mon Sep 17 00:00:00 2001
From: Vasilis
Date: Thu, 20 Jun 2024 04:04:27 +0300
Subject: [PATCH 78/80] Docs for SS14-29179 (#240)
Merge after
https://github.com/space-wizards/space-station-14/pull/29179/
---
src/en/space-station-14/mapping/guides/general-guide.md | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/en/space-station-14/mapping/guides/general-guide.md b/src/en/space-station-14/mapping/guides/general-guide.md
index eac747615..6dafbde26 100644
--- a/src/en/space-station-14/mapping/guides/general-guide.md
+++ b/src/en/space-station-14/mapping/guides/general-guide.md
@@ -39,7 +39,9 @@ A [development environment](../../../general-development/setup/setting-up-a-deve
If you are using a development enviroment instead of just hosting a local server, make sure to use Tools instead of Debug/DebugOpt mode. This is because Debug adds artificial lag (making mapping unpleasant) and crashes more (having more assertions enabled).
Additionally be careful to not use Release, which disables development environment tooling and configuration and causes the game to act like a standard server instead of a development environment.
-If you are launching via a console, you can just use:
+If you have ``runclient-Tools.bat`` and ``runserver-Tools.bat`` you can run those.
+
+If you don't have the above or want to launch via a console yourself, you can just use:
```
dotnet run --project Content.Server --configuration Tools
dotnet run --project Content.Client --configuration Tools
From a1149d77fa570c5a70581024b2617c35e55bdb4d Mon Sep 17 00:00:00 2001
From: Nemanja <98561806+EmoGarbage404@users.noreply.github.com>
Date: Sat, 22 Jun 2024 23:05:29 -0400
Subject: [PATCH 79/80] Salvage Proposal (#228)
Does what it says on the tin
solidifies salvage's place in the game and clarifies a bunch of existing
mechanics to work better in tandem
---
src/SUMMARY.md | 3 +-
.../proposals/salvage-proposal.md | 213 ++++++++++++++++++
2 files changed, 215 insertions(+), 1 deletion(-)
create mode 100644 src/en/space-station-14/departments/cargo-salvage/proposals/salvage-proposal.md
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 265570210..2194617da 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -200,7 +200,8 @@ Space Station 14
- [Cargo/Salvage](en/space-station-14/departments/cargo-salvage.md)
- [PR Guidelines](en/space-station-14/departments/cargo-salvage/guidelines.md)
- - [Proposals]()
+ - [Proposals]()
+ - [Salvage Proposal](en/space-station-14/departments/cargo-salvage/proposals/salvage-proposal.md)
- [Command](en/space-station-14/departments/command.md)
- [PR Guidelines](en/space-station-14/departments/command/guidelines.md)
diff --git a/src/en/space-station-14/departments/cargo-salvage/proposals/salvage-proposal.md b/src/en/space-station-14/departments/cargo-salvage/proposals/salvage-proposal.md
new file mode 100644
index 000000000..dff5c9c2c
--- /dev/null
+++ b/src/en/space-station-14/departments/cargo-salvage/proposals/salvage-proposal.md
@@ -0,0 +1,213 @@
+# Salvage
+
+| Designers | Implemented | GitHub Links |
+|--------------------------------|---|---|
+| EmoGarbage, Emisse, Mirrorcult | :warning: Partially | TBD |
+
+_Most of these concepts are from emisse and mirror, emo is just chronicling them all down._
+
+## Overview
+
+This proposal serves to clarify and set in a stone the design goal for the salvage subdepartment.
+Primarily, this involves the restructuring of the various gameloops they have (asteroids, wrecks, expeditions) and the modification of related systems such as ore processing, their shuttle, and other elements of the role.
+
+## Background
+
+[Mirrorcult's original salvage proposal](https://hackmd.io/@mirrorcult/salbidge)
+
+Salvage right now is in a bit of a weird spot.
+They have a decent amount of content, with a variety of tools, equipment, locations, ores, and various other things to work with.
+Cargo has a legitimate gameplay loop that salvage can integrate with and theoretically aid the station greatly.
+
+However, while all these elements _do_ exist, they aren't tied together in a way that best realizes their combined potential and lots of minor elements or issues consistently detract from the quality of the gameplay.
+
+I don't think that there's one inherent element which is terrible and ruins all of salvage.
+On the whole, there's a lot of stuff to work with and it just needs a steady hand to pull it together to deal with common issues like an excess of overly-powerful loot and being too disconnected from the station.
+
+## Round Progression
+
+Salvagers will have a soft 'progression' throughout the round in terms of the types of things they can do.
+This serves to give them more structure while also allowing them to balance the risk-reward of what they want to do.
+
+At the beginning, salvagers won't have anything beyond basic tools and will be relegated to the magnet for gathering materials.
+This is the low-skill and low-risk end of the scale, where they can get accustomed to space and basic resource collection.
+
+After salvage gets a decent amount of equipment and has enough equipment to allow them to navigate deeper into space, they can reach the mining asteroid.
+The mining asteroid has larger depots of ores as well as rare ruins and dungeons on it.
+However, it also has a greater number of threats that make it uninviting until salvage has gotten enough equipment to be able to deal with it properly.
+
+From the asteroid, in various ruins and dungeons, salvagers can retrieve **expedition disks** which enable going on individual expeditions.
+These serve as the final stage of salvaging content, with the entire team working together for an extended period of time.
+There's the most danger here but also the greatest possible reward with large dungeons and tons of ores and natural resources.
+
+## Magnet & Wrecks
+
+The salvage magnet will function basically identically to how it works in mirror's original document and how it has worked ever since [the recent major rework](https://github.com/space-wizards/space-station-14/pull/23119).
+The magnet allows salvagers to pick from a few different selections of wrecks and asteroids, giving them an overview of the general loot on them.
+
+Asteroids serve as just a way to get needed resources.
+They aren't particularly complex or difficult and can be thought of as the "chill" part of salvage.
+Wrecks on the other hand have more unique loot, including scrap and deconstructable objects as well as some weak equipment that can serve to start getting salvage on the progression to the mining asteroid.
+Wrecks may have low-level threats like weak mobs or non-fatal traps but are otherwise similar in danger to asteroids.
+
+Grids pulled from the magnet should be fairly close to it.
+Unaided by a jetpack, a salvager should be able to launch themselves from the magnet all the way to the grid.
+The only requirement for doing magnet salvage should be a suit and oxygen.
+
+The magnet should also be strictly bound to the station so as to reduce the potential for someone taking it and making it impossible for this base level work to be done.
+This is accomplished by having the magnet, if attached to a small grid like a shuttle, physically pull the shuttle towards the grid at a strength that prevents it from moving and causing damage to the hull from colliding with the asteroid/wreck.
+
+## Mining Asteroid
+
+The mining asteroid serves as the step up in difficulty from the magnet.
+
+Simply reaching the asteroid itself requires some kind of advanced transportation.
+You could use the cargo shuttle but obviously this locks up cargo orders for an extended period of time and leaves you vulnerable to getting stranded.
+Alternatively, you could build a custom small shuttle for salvage and use that to fly over to the asteroid.
+As a final resort, you could get a jetpack (optionally a handheld mass scanner as well) and just fly all the way to the asteroid.
+
+These options give salvagers a lot of variety in how they choose to get to the asteroid both in terms of speed and reliability.
+They're also not exclusive to one another and can be done at any point during the round so as to not lock them out of all options.
+
+The mining asteroid itself is significantly more dangerous than anything on the magnet.
+There are significantly more mobs which are both more numerous and dangerous as well as more traps and environmental hazards that can quickly kill unsuspecting salvagers.
+Larger structures embedded in the asteroid could also potentially contain minibosses or catastrophic threats.
+
+However, the potential for resources is significantly higher as well.
+The ore density of the mining asteroid is higher than of those pulled in from the magnet and the larger structures contain more loot than traditional wrecks.
+
+This entire package offers up a greater reward for preparing and becoming skilled enough to best the challenges on the asteroid and collect the resources on there.
+It provides variety and a bit of dangerous separation from the station while not being wholly disconnected due to the general impossibility of safety on the asteroid.
+
+Structures on the asteroid also have the potential to contain expedition disks, which leads to the final section:
+
+## Expeditions
+
+Expeditions serve as a capstone salvaging event and are only meant to appear infrequently throughout rounds.
+To gain access to an expedition, you must first locate an expedition disk somewhere on the mining asteroid, most likely gated in a dungeon or by some kind of bossfight.
+Whatever the methodology is, they should be extremely limited in number and difficult to obtain.
+
+Once the disk is obtained, the salvagers must return to the station and place it inside of the expedition console, enabling the expedition to be ran.
+Expeditions are timed planet-side operations facilitated through a large central gateway near the vault.
+
+This allows non-salvage members and potentially the whole station to participate in the expedition, allowing for a more unique gameplay opportunity than the more solo-oriented salvaging.
+
+The focus on the expedition is on the large dungeon full of goodies as well as threats and enemies.
+You can also mine and harvest from the environment, but not nearly to the same scale as wrecks/asteorids/mining asteroid in order to balance in the infinite size.
+
+Much like current wrecks, after a specified time limit (likely about 15 to 20 minutes) a final track will begin to play and players will need to make their way to the gateway in order to not be marooned on the planet.
+
+## Loot and Rewards
+
+The specific loot the salvagers retrieve has long been a contentious issue so this section seeks to clarify what exactly they'll be collecting.
+The goal is to remove problematic items and giving them greater opportunity to benefit others while still retaining the 'upgrades' of better and better equipment.
+
+### Mining and Ores
+
+Mining ores is a relatively basic thing for salvage and has a lot benefits.
+Lots of departments can use materials and rare materials are serve as progression for better equipment for salvagers.
+
+They can be harvested plentifully via magnet salvage and the mining asteroid and less commonly on expeditions.
+
+The rarity of ores is thus:
+- Iron
+- Quartz
+- Coal
+- Silver
+- Gold
+- Plasma
+- Uranium
+- Bananium
+
+**Ore processing** will also be a slightly more involved process.
+
+The goal of this is to reduce a common issue with the ore processor: utilizing it as diet infinite storage.
+People commonly bring it onto a shuttle or similar structure as it can hold an infinite amount of materials invalidating proper storage methods.
+It also enables salvagers to get processed resources for themselves while on the go and incentivizes them to take the processor with them, leading Cargo to often be without materials.
+
+My suggested solution is to make the ore processor unfeasible to run without a significantly resource intensive setup.
+The power supply alone should be impossible to manage on portable generators, requiring at least a station-level power supply.
+Furthermore, the ore processor will need a constant supply of nitrogen gas to in order to process ores into a refined state.
+
+While this is trivial to supply on-station, shuttles will have a hard time gathering enough nitrogen to produce a constant flow for the processor.
+
+### Treasure
+
+Treasure is pretty simple: it refers to any item that possesses a significant monetary value without any useful mechanical application.
+Consider fantasy crowns and jewels and gold chalices.
+These can be an exciting way to show off your wealth (who doesn't love walking around with a literal crown) while not actually affecting balance in a meaningful way.
+
+As these are solely useful for selling directly in cargo, they also serve as an incentive to return and deposit treasure in order to enrich cargo.
+
+The broad goal is just to have cool shinies that people can ogle at while not majorly disrupting any kind of balance and being useful to cargo.
+
+### Scrap
+
+Scrap refers to objects which are essentially condensed pieces of materials.
+
+These can take the form of a few different things:
+- Holdable scrap objects that can be processed into materials via a material processor inside of salvage
+- Large destroyed machinery that can be deconstructed on-site
+- Unpowered or disused on-station machines
+
+Scrap serves as a diagetic way of acquiring materials and basic parts in bulk without having to resort to just dumping a crate of steel onto the map.
+A destroyed thruster can deconstruct into 10 or 15 steel; a few of those can add up to a typical crate while also requiring more engagement in order to harvest.
+
+This is generally more important in wrecks and dungeons where filling space and interaction is an important goal.
+This is the kind of stuff that feels like actual _salvaging_.
+
+Scrap that needs to be returned to a dedicated machine to process also serves as a reason to return to the department.
+Dropping off scrap and processing it into relevant materials can be a nice source of downtime for salvagers and even cargo techs.
+
+### Department Resources
+
+Another major area for salvage is getting equipment for other departments.
+A main issue in the past is that this loot was generally more useful to salvage than to the department and thus they would often keep it rather than ever returning it to the station.
+The way to work around this is limiting items to things that don't have direct utility to salvage.
+
+Medical can receive plants and minerals that can be synthesized into batches of chemicals.
+Note that these should likely be precursor chems and not just direct omnizine or something.
+
+The bar and kitchen can receive unique flora and fauna that can be made into special drinks and meals.
+
+Science can get tech disks, research point disks, or even artifacts / artifact fragments.
+
+This isn't all encompassing: the idea is that basically everyone should be able to get something minor of value out of salvage's wrecks.
+It serves as an encouragement to return to the station and offload these items as well as fosters cooperation and relationships between different departments.
+
+## Salvager Equipment
+
+_The contentious one._
+
+Salvagers should be able to find equipment to help them better deal with threats while they are exploring wrecks and dungeons.
+In the beginning, salvagers only have the most basic equipment of a suit, belt of tools, a pickaxe, and maybe a few other basic items.
+
+### Salvage Weapons.
+
+This broadly includes the PKA, the combat knife, the dagger, the crusher, and the glaive.
+None of these would be available in the starting salvage vendor and would all have to be acquired through searching wrecks.
+
+The combat knife would be the most common with the dagger, PKA, crusher, and glaive following behind respectively.
+These items should be defined by their relative utility in the environment--mild healing, reach against mobs, or light sources--not by damage numbers.
+
+**No salvage weapon, even the most powerful ones you can find, should out-damage the captain's saber or the fireaxe.**
+
+### General Utility
+
+This just refers to equipment that grants useful abilities that salvagers would want to have.
+These can be items that can be acquired traditionally in alternative or slightly modified versions of existing items to make them more or less lucrative.
+
+It generally includes jetpacks (with and without extra capacity), large mobile light sources, gear like welding gas masks or mesons, and other various items that can serve to aid in surviving dangerous environments and moving around.
+There can also be more mild rewards like high-capacity power cells and extra oxygen tanks.
+
+The goal is just to add small rewards that help salvage either upgrade or replenish their pre-existing basic equipment without doing much else.
+
+### Blueprints
+
+Blueprints are a uncommon find on salvage wrecks that enable players to print new items off of lathes.
+Unlike tech disks or similar items that sci uses, blueprints are restricted to a singular lathe and generally focus on consumables that salvage uses regularly.
+
+This means things like mining charges, fultons, flares, etc.
+
+The intent for blueprints is to give salvage a reward in being able to replenish their own stockpiles of consumables quickly.
+It also adds variation between rounds as certain items become far more available than others as salvage unlocks blueprints at different times.
\ No newline at end of file
From ee562b33891de92023e0f5b00d6d83ab987aaa5b Mon Sep 17 00:00:00 2001
From: Vyacheslav Kovalevsky <40753025+Slava0135@users.noreply.github.com>
Date: Thu, 4 Jul 2024 09:43:06 +0300
Subject: [PATCH 80/80] vscode robust YAML extension (#248)
add mention and link to
https://marketplace.visualstudio.com/items?itemName=slava0135.robust-yaml
---
.../setup/setting-up-a-development-environment.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/en/general-development/setup/setting-up-a-development-environment.md b/src/en/general-development/setup/setting-up-a-development-environment.md
index 792cb84eb..1061df895 100644
--- a/src/en/general-development/setup/setting-up-a-development-environment.md
+++ b/src/en/general-development/setup/setting-up-a-development-environment.md
@@ -11,6 +11,7 @@ First you're gonna need some software:
* For **macOS**, [Visual Studio for Mac](https://docs.microsoft.com/en-us/visualstudio/mac/).
* For **all platforms**, (NOT FREE) [Rider](https://www.jetbrains.com/rider/) is one of the best IDEs available, and many SS14 devs prefer it over Visual Studio. College/University students can get a free education license, even if they're not a computer science major.
* For **all platforms**, [Visual Studio Code](https://code.visualstudio.com/) with the C# extension. Usually an inferior IDE experience than full blown IDEs like regular Visual Studio, but some experienced programmers enjoy the minimalism.
+ * **Exclusive to VSCode/VSCodium**: you can install our community made [Robust YAML](https://marketplace.visualstudio.com/items?itemName=slava0135.robust-yaml) extension for better Robust Toolbox YAML experience on top of [YAML Language Support](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml) extension.
* For **all platforms**, [VSCodium](https://vscodium.com/) with the C# extension. Open source and without the bloat and tracking of VSCode.
## 1. Cloning