Delta-V Wiki - User contributions [en]

Staff HQ

2026-08-18T19:34:10Z

Vape:

{| class="wikitable " style="background-color: #021d29; width: 100%;"
|+ Staff HQ Directory
|-
! <span style="color:red">All Staff</span> !! <span style="color:purple">Content Review!! <span style="color:orange">Events !! <span style="color:gold">Senior Staff
!<span style="color:lime">Administration
!<span style="color:plum">Moderation
|-
| [[Staff Policy]] || [[Direction Guidelines|Guidelines]] || [[Event Policy]]|| [[SESD TBD|Senior Staff Directory]]
|[[Whitelist|Whitelist Info]]
|[[Staff Reporting]]
|-
| [[Staff Onboarding]] || [[Content Removal]]|| ||
|[[Administrative Rulings]]
|[[Mod Policy]]
|-
|
|[[Reviewing Content With Ethos|Ethos Reviews]]
|
|
|
|
|}

Reviewing Content With Ethos

2026-08-18T19:33:30Z

Vape: Protected "Reviewing Content With Ethos" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

<sub>This goes over how to review content that has been submitted to the github with ethos. This lays out the policy for how to conduct such reviews, as well as the "Checks and Balances" of reviews.</sub>

== This Policy is currently under review, and is not active. ==

== Ethos Policy ==

1. '''CR's will review all content against the expectations of Ethos.''' <small>Minimal effort reviews such as "I don't like this" or reviews that hold little regard for our current vision and outline will '''Not''' be taken into consideration.
</small>

2. '''CR's are expected to be well versed in the specific Ethos category when placing a review of the same category.''' <small>For example, If a medical PR is made, You should be well versed in the Ethos of medical PRIOR to posting a review</small>

3. '''Reviews can and should be made against ethos when it is in the best interest of the community, or content.''' <small>If a reviewer is going against the ethos, then the review must be well structured, and list out the reasons why as well as the laying out a consideration for if Ethos should be changed, or if this is a "one-off case". If a reviewer makes a low effort review going against ethos, it will not be considered.</small>

4. '''If a PR is voted by CR to bypass Ethos, a mandatory test period of 14 days is to take place''' <small>Project Managers will be informed of the Bypass via a ping, and will work with Administration and Events to ensure that this content is adequately tested. A community feedback channel will be created, a community poll will be created at the 10 day mark, and will run for 3 days. On the 14th day, Project Management in Tandem with Content Review will examine the test period, as well as submit any proposals to change Ethos as needed.</small>

5. '''Reviews placed at any time that are derogatory or insulting to the creator of the PR will not be considered.'''

6. '''Reviewers are expected to propose changes to Ethos regularly. Ethos should be ever-evolving with the community, and should not stagnate.''' <small>If Reviewers fail to submit proposed changes to Ethos, Any Head of staff, Including Project Managers, can announce an audit of the Ethos. If no changes are proposed within 30 days of said audit, the responsibility will fall on Project Management to propose changes to Ethos in a way they see fit.</small>

7. '''Proposed Changes to the Ethos (After the preliminary period of 90 days POST-Introduction to the community) shall require a 75% Majority vote of High Command to implement.''' <small>During the 90 day period, Changes shall require a simple majority vote of High Command to establish changes. Errors and small wording changes / closing of loopholes will not require a vote, and simply 3 heads of staff to sign off. </small>

== Checks and Balances ==

1. '''If a PR that fits Ethos is denied by Content Review, any Head of Staff can bring the PR to review in High Command''' <small>A High Command vote requires a simple 50% majority. High Command can choose to request changes, Ignore CR's requested changes, Approve with no changes, or Deny. If a PR is denied by High Command, it is considered dead.</small>

2. '''If a PR is denied by Content Review, the author may form an appeal, in which case the PR must be voted on as listed above on C&B #1.''' <small>Any denial formed by content review, must disclose the option to appeal.</small>

Reviewing Content With Ethos

2026-08-18T19:19:58Z

Vape: /* Checks and Balances */

Reviewing Content With Ethos

2026-08-18T19:10:16Z

Vape:

<sub>This goes over how to review content that has been submitted to the github with ethos. This lays out the policy for how to conduct such reviews, as well as the "Checks and Balances" of reviews.</sub>

== This Policy is currently under review, and is not active. ==

== Ethos Policy ==

1. '''Content reviewers will review all content against the expectations of Ethos.''' <small>Minimal effort reviews such as "I don't like this" or reviews that hold little regard for our current vision and outline will '''Not''' be taken into consideration.
</small>

2. '''Content reviewers are expected to be well versed in the specific Ethos category when placing a review of the same category.''' <small>For example, If a medical PR is made, You should be well versed in the Ethos of medical PRIOR to posting a review</small>

3. '''Reviews can and should be made against ethos when it is in the best interest of the community, or content.''' <small>If a reviewer is going against the ethos, then the review must be well structured, and list out the reasons why as well as the laying out a consideration for if Ethos should be changed, or if this is a "one-off case". If a reviewer makes a low effort review going against ethos, it will not be considered.</small>

4. '''Reviews placed at any time that are derogatory or insulting to the creator of the PR will not be considered.'''

5. '''Reviewers are expected to propose changes to Ethos regularly. Ethos should be ever-evolving with the community, and should not stagnate.''' <small>If Reviewers fail to submit proposed changes to Ethos, Any Head of staff, Including Project Managers, can announce an audit of the Ethos. If no changes are proposed within 30 days of said audit, the responsibility will fall on Project Management to propose changes to Ethos in a way they see fit.</small>

6. '''Proposed Changes to the Ethos (After the preliminary period of 90 days POST-Introduction to the community) shall require a 75% Majority vote of High Command to implement.''' <small>During the 90 day period, Changes shall require a simple majority vote of High Command to establish changes. Errors and small wording changes / closing of loopholes will not require a vote, and simply 3 heads of staff to sign off. </small>

== Checks and Balances ==

1. '''If a PR that fits Ethos is denied by Content Review, any Head of Staff can bring the PR to review in High Command''' <small>A High Command vote requires a simple 50% majority. High Command can choose to request changes, Ignore CR's requested changes, Approve with no changes, or Deny. If a PR is denied by High Command, it is considered dead.</small>

2. '''If a PR is denied by Content Review, the author may form an appeal, in which case the PR must be voted on as listed above on C&B #1.''' <small>Any denial formed by content review, must disclose the option to appeal.</small>

Reviewing Content With Ethos

2026-08-18T19:09:39Z

Vape: Establishment of Ethos Guidelines

<sub>This goes over how to review content that has been submitted to the github with ethos. This lays out the policy for how to conduct such reviews, as well as the "Checks and Balances" of reviews.</sub>

== Ethos Policy ==

1. '''Content reviewers will review all content against the expectations of Ethos.''' <small>Minimal effort reviews such as "I don't like this" or reviews that hold little regard for our current vision and outline will '''Not''' be taken into consideration.
</small>

2. '''Content reviewers are expected to be well versed in the specific Ethos category when placing a review of the same category.''' <small>For example, If a medical PR is made, You should be well versed in the Ethos of medical PRIOR to posting a review</small>

3. '''Reviews can and should be made against ethos when it is in the best interest of the community, or content.''' <small>If a reviewer is going against the ethos, then the review must be well structured, and list out the reasons why as well as the laying out a consideration for if Ethos should be changed, or if this is a "one-off case". If a reviewer makes a low effort review going against ethos, it will not be considered.</small>

4. '''Reviews placed at any time that are derogatory or insulting to the creator of the PR will not be considered.'''

5. '''Reviewers are expected to propose changes to Ethos regularly. Ethos should be ever-evolving with the community, and should not stagnate.''' <small>If Reviewers fail to submit proposed changes to Ethos, Any Head of staff, Including Project Managers, can announce an audit of the Ethos. If no changes are proposed within 30 days of said audit, the responsibility will fall on Project Management to propose changes to Ethos in a way they see fit.</small>

6. '''Proposed Changes to the Ethos (After the preliminary period of 90 days POST-Introduction to the community) shall require a 75% Majority vote of High Command to implement.''' <small>During the 90 day period, Changes shall require a simple majority vote of High Command to establish changes. Errors and small wording changes / closing of loopholes will not require a vote, and simply 3 heads of staff to sign off. </small>

== Checks and Balances ==

1. '''If a PR that fits Ethos is denied by Content Review, any Head of Staff can bring the PR to review in High Command''' <small>A High Command vote requires a simple 50% majority. High Command can choose to request changes, Ignore CR's requested changes, Approve with no changes, or Deny. If a PR is denied by High Command, it is considered dead.</small>

2. '''If a PR is denied by Content Review, the author may form an appeal, in which case the PR must be voted on as listed above on C&B #1.''' <small>Any denial formed by content review, must disclose the option to appeal.</small>

Staff HQ

2026-08-18T18:40:04Z

Vape: Expansion of the table

Administrative Rulings

2026-08-18T18:39:03Z

Vape: Updates from pink skunks to ping host

{{Important|Title=Making changes to this page|Note=You need to be in the projectstaff wiki group to be able to edit this page, ping our host to be added to it. If you don't have access yet, please post missing rulings in [https://discord.com/channels/968983104247185448/1486398865459515574 this #admin-general thread] or on the [[Talk:Administrative Rulings|talk page]].|Color=#ffffff|Image=BookSpaceLaw.png}}

== Concerning antagonists ==

=== General ===
* The positronic brain of a Borg <span style="color:green">may be</span> shut off and disposed of by an antagonist if it witnessed a crime. {{AnchorLink|antag-posi-shutoff}}
** We strongly suggest you turn the brain back on afterwards, so the Borg player can continue playing their role. However, not doing so is not a rule-break per se.
** This ruling was put in place because there is no functioning Borg death system.

=== Antagonistic Ghost Roles ===
* Playing Xeno, Rat King, Entropic Colossus and similar ghost roles as non-hostile is <span style="color:red">not allowed</span>. {{AnchorLink|antag-ghostroles-friendly}}
** <span style="color:green">You may</span> feign friendliness towards crew to mislead and trap them or otherwise aid you in your objectives.

=== Cosmic Cultists ===
* Cultists <span style="color:red">may not</span> place the monument off-station. It must be placed on the station's grid. {{AnchorLink|cosmic-monument-placement}}

=== Revenants ===

* Revenants <span style="color:red">may not</span> spill jugs, drag people or interact with the round in other unintended ways <span style="background-color:yellow;color:black;">while they are invisible</span>. {{AnchorLink|revenant-spill-drag-invis}}
** '''The Revenant being able to melee people while invisible is <span style="color:green">intended</span>.'''
** ''Rule of thumb:'' If you can do something as an invisible, invincible ghost to affect other players and it's not specifically advertised as a power of the Revenant, you probably shouldn't be doing it. Counterplay to your antagonistic actions should be possible.
** This is considered excessively lame and borderline bug-abuse.

=== Space Ninjas ===
* Ninjas <span style="color:green">may be</span> treated as crit-to-detain or KOS, even if they have not taken antagonistic action yet. {{AnchorLink|ninjas-kos}}
** You should still respect their attempts at roleplay.

=== Nuclear Operatives ===
* Nukies <span style="color:green">may</span> round-remove crew for any reason. They are not tied to round-removal rules. {{AnchorLink|nukies-rr-crew}}
** You should still be focused on blowing up the station as a Nukie:
*** <span style="color:green">Do</span> feel free to round-remove crew you come across while completing your objective.
*** <span style="color:red">Don't</span> roam the station focused solely on finding and round-removing as many people as you can.

=== Traitors ===
* Crew, including Security, <span style="color:green">may</span> capture and compromise syndicate comms with proper permits. {{AnchorLink|traitors-comms-compromise}}
* Crew <span style="color:red">may not</span> test for disguised items, '''even after discovering an open uplink'''. {{AnchorLink|traitors-disguised-items-uplink}}
** This means you should never assume toys or other disguised items are illegal gear just because you know such items exist. There has to have been a strong indication that the item is not what it seems, such as seeing it in use or seeing a situation that cannot be explained in any other way, for you to confiscate it.
** As is explicitly stated in the [[Metashield]]: ''Stealth items should not be "tested" for their functionality, but items that are clearly producing some sort of stealth effect can be confiscated.''
* Traitors <span style="color:red">may not</span> assist Nuclear Operatives, including Lone Operatives, unless they have the "Die a glorious death" objective. {{AnchorLink|traitors-no-elp-nukie}}

=== Zombies ===

* Zombies <span style="color:red">may not</span> attack borgs unless they were provoked. {{AnchorLink|zombies-borg-attack}}
** They do not inherently view them as food.
** If provoked, <span style="color:green">they may</span> continue attacking the borg until their chassis is destroyed.
* Zombies <span style="color:red">may not</span> attack or destroy structures unless they know there is food (living beings) behind them. {{AnchorLink|zombies-structure-damage}}
* Zombies <span style="color:red">may not</span> be non-hostile. {{AnchorLink|zombies-always-hostile}}
* Zombies <span style="color:red">may not</span> hide in disposal chutes or flush them. {{AnchorLink|zombies-chutes}}

== Concerning other roles ==

=== Prisoner ===

* Prisoners <span style="color:red">may not</span> seek to escape Perma without reason, but <span style="color:green">they may</span> escape opportunistically if presented with a significant opportunity. {{AnchorLink|prisoner-escape-opportunity}}
** This means you should not run out of the perma airlock every time it is opened, but you could escape if, for example, a Traitor blew a hole into wall to facilitate your escape.
** Your character does not have to like being in perma. They can absolutely want to be free, but keep in mind Prisoner is not an antagonistic role.

== Concerning mechanics ==
=== General ===
* Felinids and other species that can enter duffel bags <span style="color:red">may not</span> abuse this mechanic to avoid being damaged. {{AnchorLink|felinid-bag-cheese}}
** This means: They may hide in them if they are still "undetected", but they should not enter a bag during combat or while being pursued in order to make being damaged impossible.

=== Borging ===
* Any laws you receive after being borged supersede your antag objectives. {{AnchorLink|borging-objectives}}
** This means: A borged nukie in a Crewsimov chassis <span style="color:red">may not</span> attack people.

=== Engineering ===
* GarTEGs and other constructions that abuse game implementation details to produce something in vast quantities are <span style="color:red">not allowed</span>. {{AnchorLink|garteg}}
** They make little sense ICly, look and feel unsafe and are generally too "game-y".
** ''Rule of thumb:'' The things you construct should make sense and not recklessly expose other crew to danger from an IC perspective.

== Concerning specific rules ==

=== [[Server Rules#S4. You cannot request or allow a law change|S4 - You cannot request or allow a law change]] ===

* Borgs <span style="color:red">may not</span> directly request for the station AI to override their laws. {{AnchorLink|s4-borg-ai-request}}
** They <span style="color:green">may</span> work around this by, for example, mentioning to the AI that a specific law is preventing them from accomplishing a specific task.

=== [[Metashield|B2 - Metashield]] ===
* The "Current gamemode, and any antagonists that could exist as a result" shield <span style="color:red">prohibits</span> attempts at guessing the gamemode based on otherwise innocuous character behavior. {{AnchorLink|metashield-no-guessing}}
** This means: If someone orders monkey cubes and Zombies have not been called out yet, you should not assume they are an Initial Infected. Your character should not anticipate an attack like this without a sound current-round reason.

File:Spacemap3.png

2026-08-15T20:05:46Z

Vape:

From wizden

Template:Main Page Header

2026-08-15T19:39:48Z

Vape: updated logo again

<td colspan="3" style="padding:1px; width:100%; min-width:900px; margin-bottom:10px;">
<div style="border:solid #000 1px; background-color:#000a1e;">[[File:logo clean pride.png|center]]
<div style="color:#ffffff; text-align:center; font: 24px Arial Black, Calibri, sans-serif; text-shadow: 2px 0 #1b2942, 0 -2px #1b2942, -2px 0 #1b2942, 0 2px #1b2942; margin-bottom:10px;">Welcome to the Delta-V Wiki</div>
<div style="text-align:center; font-size:85%; border:none; margin:0; margin-bottom:5px; padding:.1em; color:#ffffff;"> Please feel free to [[Wiki Contribution|contribute]] by creating a new article or expanding upon an existing one.</div>
</div></td>

File:Logo clean pride.png

2026-08-15T19:38:57Z

Vape:

By Kazne

File:Splashlogov2.png

2026-08-15T19:31:49Z

Vape:

By Kazne, hopefully resized

Template:Main Page Header

2026-08-15T19:28:32Z

Vape: Uploading new logo's

<td colspan="3" style="padding:0px; width:100%; min-width:560px; margin-bottom:10px;">
<div style="border:solid #000 1px; background-color:#000a1e;">[[File:splashlogo.png]]
<div style="color:#ffffff; text-align:center; font: 24px Arial Black, Calibri, sans-serif; text-shadow: 2px 0 #1b2942, 0 -2px #1b2942, -2px 0 #1b2942, 0 2px #1b2942; margin-bottom:10px;">Welcome to the Delta-V Wiki</div>
<div style="text-align:center; font-size:85%; border:none; margin:0; margin-bottom:5px; padding:.1em; color:#ffffff;"> Please feel free to [[Wiki Contribution|contribute]] by creating a new article or expanding upon an existing one.</div>
</div></td>

File:Splashlogo.png

2026-08-15T19:27:21Z

Vape:

by Kazne

Template:Main Page Quicklinks

2026-08-15T19:23:02Z

Vape: fixing a dummy error

<td colspan="3" style="padding:0px; width:100%; min-width:560px; margin-bottom:10px;"><div style="border:solid #000000 1px; background-color:#1b2942C2;">

<div style="background-color:#000a1e; width:100%; text-align:center; font: 21px Calibri, sans-serif; padding:2px 0 2px 0;">Quick links</div>

<table style="width:100%; text-align:center; font: 18px Calibri, sans-serif;">
<tr>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:Passenger.png|64px|link=Getting Started]]</td></table>[[Getting Started]]
</div></td>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:BookTrialLaw.png|64px|link=Server_Rules]]</td></table>[[Server Rules|Rules]]
</div></td>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:BookEngineering.png|64px|link=Guides]]</td></table>[[Guides]]
</div></td>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:BlankID.png|64px|link=Jobs]]</td></table>[[Jobs]]
</div></td>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:GPS.gif|64px|link=Maps]]</td></table>[[Maps]]
</div></td>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:Traitor.png|64px|link=Game Modes]]</td></table>[[Game Modes]]
</div></td>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:Mop.png|64px|link=Interactions]]</td></table>[[Interactions|Keyboard Shortcuts]]
</div></td>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:Telescreen.png|64px|link=https://deltav.gay/replays/apoapsis/]]</td></table>[https://deltav.gay/replays/apoapsis/ Replays]
</div></td>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:Wrench.png|64px|link=https://docs.spacestation14.com/]]</td></table>[https://docs.spacestation14.com/ Development]
</div></td>

</tr>
</table></div>
</td>

Template:Main Page Quicklinks

2026-08-15T19:20:00Z

Vape: Updates to the Interactions page, as this is not self descriptive for new players.

<td colspan="3" style="padding:0px; width:100%; min-width:560px; margin-bottom:10px;"><div style="border:solid #000000 1px; background-color:#1b2942C2;">

<div style="background-color:#000a1e; width:100%; text-align:center; font: 21px Calibri, sans-serif; padding:2px 0 2px 0;">Quick links</div>

<table style="width:100%; text-align:center; font: 18px Calibri, sans-serif;">
<tr>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:Passenger.png|64px|link=Getting Started]]</td></table>[[Getting Started]]
</div></td>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:BookTrialLaw.png|64px|link=Server_Rules]]</td></table>[[Server Rules|Rules]]
</div></td>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:BookEngineering.png|64px|link=Guides]]</td></table>[[Guides]]
</div></td>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:BlankID.png|64px|link=Jobs]]</td></table>[[Jobs]]
</div></td>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:GPS.gif|64px|link=Maps]]</td></table>[[Maps]]
</div></td>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:Traitor.png|64px|link=Game Modes]]</td></table>[[Game Modes]]
</div></td>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:Mop.png|64px|link=Interactions]]</td></table>[[Keyboard Shortcuts]]
</div></td>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:Telescreen.png|64px|link=https://deltav.gay/replays/apoapsis/]]</td></table>[https://deltav.gay/replays/apoapsis/ Replays]
</div></td>

<td style="width:11.1%;"><div style="padding: 10px 0 10px 0;"><table align=center><td style="padding:0px;">
[[File:Wrench.png|64px|link=https://docs.spacestation14.com/]]</td></table>[https://docs.spacestation14.com/ Development]
</div></td>

</tr>
</table></div>
</td>

Direction Guidelines

2026-07-15T19:27:40Z

Vape: Review pol update

{{DISPLAYTITLE:Content Review Guidelines}}
{{DISPLAYTITLE:Content Review Guidelines}}

=== Overview ===
This page goes over Content Review, and How to perform these. This goes into detail about CR policy, Design Documents, Content removal, and more.

== Content Review Policy ==
<small>Any portion of the Content Review Policy can be suspended, or overridden by the Content Director at any time.</small>

1. The '''Content Review Team''' is expected to submit a roadmap to the '''Content Director''' and '''Project Management''' for review when possible.

2. Content Reviewers are expected to fulfill their duties without bias. Submission of PR’s that can be considered without merit or otherwise heavily biased, should be considered for denial.

3. Content Reviewers are required to have a basic understanding of how PR Submission works, and how to use Github.

4. Using the "Raised Issue" system, Content Reviewers must have a generalized understanding of how to use this system

5. Content Reviewers cannot override issues on their own PR. The author is allowed to advocate, represent, clarify, and generally engage in conversation.

6. Extended lawyering of PR Reviews is not allowed. Reviewers should focus on raising an issue, asking questions, and choosing a stance.

7. Only Senior Content Reviewers may triage or finalize decisions regarding a PR with the standard review policy.

8. No Content Reviewer may triage or end reviews for their own PR.

9. Content Reviewers should be reasonably up to date and knowledgeable about the game and its intricacies.

==Making a Roadmap==

Developing a roadmap is a multi-step process. Concepts on the roadmap should be selected by the team privately, and the ideas should be established to a level of certainty before being presented for community feedback. Concepts can be specific or broad, as long as they have a “Solid final goal” that the team can guide contributors to. The creation of a roadmap can be broken down in specific steps.

1. '''Observation & Collection''' - Observe Discord channels, forums, and in-game interactions. Observing what players are discussing, what they enjoy, and what challenges they face. Monitor dedicated feedback channels, collect suggestions, and identify recurring themes or requests.

2. '''Conceptualization''' - after Observing & collecting data, rank Concepts by the following. This is done privately in the #roadmap-development forum.

*'''Content impact''' - Is the content aligned with our mission

*'''Technical Feasibility''' - What skills are needed for this?

*'''Breakdown''' - Break topics down into steps

*'''Community Interest''' - Is the community interested in this? Is this something that they would take kindly to?

*'''Priority''' - How necessary does the team believe this is? are there external pressures pushing for this?

3. '''Requirement Gathering''' - After ranking of Concepts, you should itemize out the following Requirements

*'''What does this concept seek to do?'''

*'''What does this change or add?'''

*'''What problems are addressed?'''

4. '''Solution Design''' - This is the stage of turning the “What” from Step 3 into the “How”. For every problem or requirement, break these down into a list of “actionable tasks”. For example, if a requirement is to "create a new player model," a Solution Design task would be "create a specific sprite for the new player model."

*Determine what actions and changes need to be done

*Itemize these into tasks, as small as possible. Are sprites needed? Ask for a specific sprite.

5. '''Publication''' - At this stage, you will share a “draft” of the design with the public, and collect community feedback. You should use this feedback to flesh out a finalized roadmap for contributors.

== Design Documents ==

Design Documents are a tool for the community to outline and present ideas. Design Documents should use the provided Design Document template.

The community can create DD prior to opening a PR, and have them reviewed by direction to “fine tune” their ideas to Direction standards before starting development. The Community can also create DD for review without the intention to develop them personally. Contributors can always claim approved documents and begin development themselves.

Curators can collaboratively create DD to address issues laid out in the roadmap. These documents serve as the “Solution design” step of the roadmap.

Curators may prioritize certain DD depending on Content Management's needs and goals.

= Content Review =

Reviewing suggested content involves examining current Pull Requests (PRs) or Design Documents (DD) and providing feedback. Content review should involve as many members as possible. If only one or two choose to review, their opinion holds the same weight as the entire team. If the rest of the team comes to a different decision at a later date, content can always be reverted.

==== All content must pass the full review process before being approved ====
with a few small exceptions. Proposed changes listed below do not require review:

*Bug fixes

*Simple tweaks

*Obvious small changes

*Additions or changes deemed by the Content Director or Senior CR's to be minor or essential (<small>this includes upstream merges</small>)

When in doubt, the team should be asked if a review is needed.

==What to look for in a review==

*Fits our MRP standard - Keeps the balance between action and roleplay, no overpowered things that break the fun. We want things to make sense in the setting.

*Fits the Design Ethos - We are a server founded in analogue design. We want this to be displayed in all content that we merge, such that it fits the mechanical narrative of the game.

==How to conduct a review==

Content Reviews should take place in either the #public-content-review or the #private-content-review forum channels. The Senior Content Reviewer who creates a Content Review post assumes responsibility for providing feedback to the author. This includes notifying the author that the content is under review, and summarizing feedback gathered in the review to provide the next steps to the author.

Content Review is not a vote. Content Review's take place with a raised issue system. If you have an issue with something in the PR, you should raise an issue using the Content Review bot using the small guide below:

# Send a message outlining your issue with the PR.
# Hover over the message.
# Hover over <code>Apps</code>.
# Hover over <code>Delta-V Bot</code>.
# Click on <code>Raise Issue</code>. The message you send will be pinned and viewable by entering the command <code>/cr issue overview</code>. With every reminder message sent by the bot, the ratio of issues and overrules will be displayed. The same way is done to overrule issues.

If an issue is not addressed, it must wait until the end of a review period. At the end of a review, the Senior Content Reviewer who initiated review, will tally both issues and overrides, and then determine whether the issues will prevent a PR from being merged. This includes requesting changes, applying a test merge, approving the PR as is, or denying the PR. <small>This can be overridden by the Content Director at any time.</small>

Any final decisions must be communicated to the content author through appropriate channels. This will vary between PRs and DD. Design Document (DD) review takes place within Discord. Feedback should be provided within the original DD post in the forum.

Decisions include:
Approval
Approval with priority
Approval with test merge
Requesting changes
Denial

⚠️Maintainers have the final authority when it comes to the fitness of the PR in terms of code quality and bugs or other mechanical concerns.⚠️

== PR Deadlines ==

Deadlines are required when reviewing new content. Deadlines are relative to the size of the content. The standard method of tracking these deadlines is to create a poll with the appropriate duration in the review post.

* Small changes are subject to 24 - 48 hours of consideration

* Major changes are subject of up to 7 days of consideration. <small>this can be extended at any time with approval from a Senior CR or the Content Director</small>

'''The minimum time for official review is 24 hours.''' <small>This can be shortened at any point with approval from a Senior CR or the Content Director</small>

CR's should notify authors when the content is placed into official review, and give them an estimated wait time for feedback. If more time is required, the author should be notified.

If, after 10 days without input or a consensus, CR will be considered '''Stalemated''', The final decision to test merge should be made by the head maintainer, or the maintainer handling the PR. Direction may request the content be reverted at a later date after a 14 day test process, and acquiring proper community feedback. <small>This only applies to PR's, and does not apply to design documents.</small>

== Upstream Merges ==

Upstream merges are an incredibly complex "update" that is brought into the server from Wizards Den (our upstream). This involves many "refactors" and changes to systems that make our codebase more stable, and able to run more efficiently.

After each upstream merge, if this contains more than 2 weeks of content, there is a '''Mandatory''' 3 day PR freeze. <small>This may be changed or removed at any time by any head of development</small>

Event Policy

2026-06-09T23:19:54Z

Vape: Updates to event policy

''This policy refers to Administrators and Curators, Unless otherwise specified.''

1. '''Actions of Staff during round must be reported to the #Event-log in discord.''' <small>This includes all “One-off” spawns. Spawns and actions pertaining to an approved event can be skipped as long as the event itself has been reported. Major changes to an event in-round must be logged. This excludes small actions that are taken to preserve the integrity of the game, such as moving players & addressing small bugs.</small>

2. '''<span style="color:red;">Never''' '''use a “smite” against a player character that is in round.''' <small>This includes possible raiders. Smites have the capacity to be irreversible and game breaking. They should not be used outside of the admin arena.</small>

3. '''Events should be allowed to play out at their own pace.''' <small>Events will almost invariably be affected by the crew, antagonists, or natural occurrences within the round; let the round flow organically and allow players to interact with the event rather than forcing them to follow a script. Let them fail if needed.
</small>

4. '''Events must meet or exceed our MRP Standard.''' <small>Both the rationale and implementation of an event must demonstrate evidence of a story, or be beneficial to the story unfolding on the station currently.</small>

5. '''Events must not feature staff-level ghost roles such as deathsquad unless directly authorized by a Head of Staff.''' <small>These roles should be filled by staff and represent both Administration and Curation in an in-character fashion.</small>

6. '''Events should never portray ''<span style="color:cyan;">NanoTrasen'' or ''<span style="color:green;">Central Command'' as directly antagonistic to the crew.''' <small>While Central Command is expected to be strict - especially on matters of policy and procedure - they should be supportive where possible, politely evasive when pressed, and only authoritative in extreme circumstances.</small>

7. '''Events should not disrupt the balance of the round.''' <small>Don't introduce overpowered, unique, or usually unobtainable ghost roles, entities, or items, and should not overwhelm the round, the station, or its resources. This includes objective items, spawn-only items, leviathings, etc.</small>

8. '''Event roles should be reserved for players.''' <small>Staff are expected to organize and oversee the event, not partake in it. If a ghost role is not taken for '''<span style="color:yellow;">more than 5 minutes''', the eventing staff member may join the queue .</small>

9. '''aGhosts are welcome to take any ghost roles.''' <small>Refer to the previous rule regarding roles you have spawned.</small>

10. '''Do not test unknown commands on the game servers.''' <small>All testing of Console commands, VVwrites, and other “Unused” aGhost powers should take place on a personal dev environment, not on the game servers.</small>

11. '''You may not take ERT Leadership roles unless 5 minutes has passed without anyone taking the role.'''

12. '''Any spawned CC character going to the station, must be armed by security on station.''' <small><span style="color:red;">If your character is visiting the station or leaving CC in any capacity, You are not allowed to spawn weapons for them. You may take 1 sidearm EQUIVALENT to the one spawned by the loadout menu.</small>

= Event Categories =

* '''<span style="color:green;">Low Impact''' - '''<span style="color:green;">Trial-Game Administrators''' / '''<span style="color:orange;">Trial-Curators''' <small>or above without approval.</small>
Low impact events either:
* Do not interact with players in a meaningful way
* Are a direct response to a player request or interaction, and do not affect the round to a greater degree
-> Such as responding to faxes or answering prayers

* '''<span style="color:yellow;">Medium Impact''' - '''<span style="color:green;">Trial-Game Administrators''' / '''<span style="color:orange;">Trial-Curators''' <small>with approval from a '''<span style="color:orange;">Curator'''.</small> '''<span style="color:green;">Game Administrators''' / '''<span style="color:orange;">Curators''' <small>without approval.</small> '''<span style="color:orange;">Senior Curators''' / '''<span style="color:green;">Senior Administrators''' <small>and above do not need approval.</small>
Medium impact events either
* Considerable affect players or the round without derailing the round, round-removing
players, or taking significant resources and manpower from departments.
* Add a new gamerule unlikely to cause significant effect on players or the round
* Are a direct response to a player request or interaction that affects the round to a considerable degree.
-> Such as adding a Clown Spider spawn or adding a single round ending antag

* '''<span style="color:red;">High Impact''' - <small>Following the mandatory notice and when approved by a</small> '''<span style="color:orange;">Senior Curator''' <small>or above.</small>
High impact events either:
* Heavily affect players or the round, possibly derailing the round, round-removing
players, or taking significant resources and manpower from departments
* Add a new gamemode, causing significant effect on players or the round
* Are a direct response to a player request or interaction that results in a High Impact event.
-> Some Examples include setting the game mode or spawning multiple round ending antagonists

⚠️'''<span style="color:red;">High impact events must be planned, written in Directions event library, and approved. Additionally, a mandatory 30 minute notice must be posted & *approved* in the event log prior to running these events, unless otherwise authorized by at least *2 Senior Curators, or 1 Head of Staff*. An event plan should include entity/role requirements, event goals, players and departments involved, and “Staffing” needs.'''⚠️

== Exceptions to event policy ==

1. '''Staff are permitted to spawn in Central Command characters for the purpose of greeting crew or writing faxes.''' <small>CC Characters should be competent, reasonably named, and disconnected from any “In-game” characters.</small>

2. '''Staff are permitted to create ghost bars.''' <small>Spawning ghost roles on a separate map from the station for the purpose of a gag, sandbox construction, ETC</small>

3. '''Staff are permitted to remodel “Midpoint” to reflect events that occurred during the round, and to remodel “Midpoint” to reflect a more artistic and “Destressed” environment for players to end their round.''' <small>The latter requires appropriate documentation in the Event-log, and following “Medium-Impact” approval</small>

4. '''Staff are permitted to Spawn ERT following the chart listed below.''' <small><span style="color:red;">Any exceptions require approval from a Senior Administrator/Senior Curator or above.</small>

[[File:ERT chart.jpg|thumb]]

= Epsilon Procedure =

<span style="color:red;">''In the event that Epsilon is or will be needed, Permission is required by a <span style="color:orange;">HEAD OF STAFF or SENIOR CURATOR. <span style="color:red;">If either of these options are unavailable after 10 minutes, you may call gamma and resolve the situation without violence.

Event Policy

2026-06-09T23:01:46Z

Vape: Updates and grammatical / organizational maintenance

''This policy refers to Administrators and Curators, Unless otherwise specified.''

1. '''Actions of Staff during round must be reported to the #Event-log in discord.''' <small>This includes all “One-off” spawns. Spawns and actions pertaining to an approved event can be skipped as long as the event itself has been reported. Major changes to an event in-round must be logged. This excludes small actions that are taken to preserve the integrity of the game, such as moving players & addressing small bugs.</small>

2. '''<span style="color:red;">Never''' '''use a “smite” against a player character that is in round.''' <small>This includes possible raiders. Smites have the capacity to be irreversible and game breaking. They should not be used outside of the admin arena.</small>

3. '''Events should be allowed to play out at their own pace.''' <small>Events will almost invariably be affected by the crew, antagonists, or natural occurrences within the round; let the round flow organically and allow players to interact with the event rather than forcing them to follow a script. Let them fail if needed.
</small>

4. '''Events must meet or exceed our MRP Standard.''' <small>Both the rationale and implementation of an event must demonstrate evidence of a story, or be beneficial to the story unfolding on the station currently.</small>

5. '''Events must not feature staff-level ghost roles such as deathsquad unless directly authorized by a Head of Staff.''' <small>These roles should be filled by staff and represent both Administration and Curation in an in-character fashion.</small>

6. '''Events should never portray ''<span style="color:cyan;">NanoTrasen'' or ''<span style="color:green;">Central Command'' as directly antagonistic to the crew.''' <small>While Central Command is expected to be strict - especially on matters of policy and procedure - they should be supportive where possible, politely evasive when pressed, and only authoritative in extreme circumstances.</small>

7. '''Events should not disrupt the balance of the round.''' <small>Don't introduce overpowered, unique, or usually unobtainable ghost roles, entities, or items, and should not overwhelm the round, the station, or its resources. This includes objective items, spawn-only items, leviathings, etc.</small>

8. '''Event roles should be reserved for players.''' <small>Staff are expected to organize and oversee the event, not partake in it. If a ghost role is not taken for '''<span style="color:yellow;">more than 5 minutes''', the eventing staff member may join the queue .</small>

9. '''aGhosts are welcome to take any ghost roles.''' <small>Refer to the previous rule regarding roles you have spawned.</small>

10. '''Do not test unknown commands on the game servers.''' <small>All testing of Console commands, VVwrites, and other “Unused” aGhost powers should take place on a personal dev environment, not on the game servers.</small>

11. '''You may not take ERT Leadership roles unless 5 minutes has passed without anyone taking the role.'''

12. '''Any spawned CC character going to the station, must be armed by security on station.''' <small><span style="color:red;">If your character is visiting the station or leaving CC in any capacity, You are not allowed to spawn weapons for them.</small>

= Event Categories =

* '''<span style="color:green;">Low Impact''' - <small>These events may be run by</small> '''<span style="color:green;">Trial-Game Administrators''' / '''<span style="color:orange;">Trial-Curators''' <small>or above without approval.</small>
Low impact events either:
* Do not interact with players in a meaningful way
* Are a direct response to a player request or interaction, and do not affect the round to a greater degree
-> Such as responding to faxes or answering prayers

* '''<span style="color:yellow;">Medium Impact''' - <small>These events may be run by</small> '''<span style="color:green;">Trial-Game Administrators''' / '''<span style="color:orange;">Trial-Curators''' <small>with approval from a second (non-trial) Staff member.</small> '''<span style="color:green;">Senior Administrators''' / '''<span style="color:orange;">Senior Curators''' <small>and above do not need approval.</small>
Medium impact events either
* Considerable affect players or the round without derailing the round, round-removing
players, or taking significant resources and manpower from departments.
* Add a new gamerule unlikely to cause significant effect on players or the round
* Are a direct response to a player request or interaction that affects the round to a considerable degree.
-> Such as adding a Clown Spider spawn or adding a single round ending antag

* '''<span style="color:red;">High Impact''' - <small>These events may be run following the mandatory notice (when applicable) and when approved by a</small> '''<span style="color:orange;">Senior Curator''' / '''<span style="color:green;">Senior Administrator''' <small>or above.</small>
High impact events either:
* Heavily affect players or the round, possibly derailing the round, round-removing
players, or taking significant resources and manpower from departments
* Add a new gamemode, causing significant effect on players or the round
* Are a direct response to a player request or interaction that results in a High Impact event.
-> Some Examples include setting the game mode or spawning multiple round ending antagonists

⚠️'''<span style="color:red;">High impact events must be planned, written in Directions event library, and approved. Additionally, a mandatory two hour notice must be posted in the event log prior to running these events, unless otherwise authorised by at least a Senior Administrator, Senior Curator, or Head of Staff. An event plan should include entity/role requirements, event goals, players and departments involved, and “Staffing” needs.'''⚠️

== Exceptions to event policy ==

1. '''Staff are permitted to spawn in Central Command characters for the purpose of greeting crew or writing faxes.''' <small>CC Characters should be competent, reasonably named, and disconnected from any “In-game” characters.</small>

2. '''Staff are permitted to create ghost bars.''' <small>Spawning ghost roles on a separate map from the station for the purpose of a gag, sandbox construction, ETC</small>

3. '''Staff are permitted to remodel “Midpoint” to reflect events that occurred during the round, and to remodel “Midpoint” to reflect a more artistic and “Destressed” environment for players to end their round.''' <small>The latter requires appropriate documentation in the Event-log, and following “Medium-Impact” approval</small>

4. '''Staff are permitted to Spawn ERT following the chart listed below.''' <small><span style="color:red;">Any exceptions require approval from a Senior Administrator/Senior Curator or above.</small>

[[File:ERT chart.jpg|thumb]]

= Epsilon Procedure =

<span style="color:red;">''In the event that Epsilon is or will be needed, Permission is required by a <span style="color:orange;">HEAD OF STAFF or SENIOR CURATOR. <span style="color:red;">If either of these options are unavailable after 10 minutes, you may call gamma and resolve the situation without violence.

SESD TBD

2026-05-22T02:09:59Z

Vape:

{{DISPLAYTITLE:Senior Staff Directory}}

== Senior Staff Guidelines ==
Senior Staff generally are encouraged to assist heads by performing assigned tasks. This document has been made to list out some of those tasks that are "Regular Occurrences" and the expectations of what Senior level staff are expected to do / Perform. This document, while official, is subject to change at any time with the request of the direct head of staffs request. Senior Staff are expected to understand what they are empowered to perform, and what should be taken to a head.

=== Senior Content Review ===
Senior Content Reviewers are expected to:

* Ensure Reviews are performed in a timely manner
* Be knowledgeable on the Review Policy, and at times, encourage reviewers to stick to this policy
* Make decisions regarding the need for a review
* Make decisions regarding Test Merges
* Assist the Content Director with any additional tasks that are needed / requested
* Assist in continuance of training regarding new reviewers, and should be capable of explaining "How To" perform the daily tasks of a Content Reviewer

Should a scenario occur where policy is not being followed, and a simple encouragement does not suffice, Seniors are expected to report this to the Content Director, without taking this into their own hands.

=== Senior Moderation ===
Senior Moderators are expected to:

* Perform in-depth investigations into Mhelps
* Perform in-depth investigations into staff reports that are relevant to their accesses
* Assist the Head Moderator in ongoing investigations that their access allows
* Educate and Guide new moderators with Mod Policy
* Should be capable of stepping into a ticket should a Mod become overwhelmed or overstepped

Should a scenario occur where policy is not being followed, and a simple encouragement does not suffice, Seniors are expected to report this to the Head Moderator, without taking this into their own hands.

=== Senior Administration ===
Senior Administrators are expected to:

* Provide Guidance on rulings that are complex to Admins
* Refer to previous rulings on similar situations, and make similar rulings as needed
* Understand how to perform Log Diving investigations, and be capable of teaching this to Trials and Game admins
* Be knowledgeable in the rules, and capable of identifying what rules have been broken
* Encourage Game admins and Trials to follow rulings, and to not intervene in situations that should be handled "In Character"
* Be capable in defusing a situation, whether this is between staff or players
* Should be capable of stepping into a ticket should an Admin become overwhelmed or overstepped
* Regularly check Senior Admin Channels and forums for important information and changing dynamics as informed by the headmins.

Should a scenario occur where policy is not being followed, and a simple encouragement does not suffice, Seniors are expected to report this to the Head Administrator, without taking this into their own hands. Should a scenario occur where a clear violation of Admin Policy is in order, Senior Admins are suggested to form a Staff report with relevant information.

=== Senior Curators / Eventers ===

Staff HQ

2026-05-22T02:09:28Z

Vape:

Alert Procedure

2026-05-19T01:34:14Z

Vape: removed "Sheilds" from green alert

== <span style="color:#4f8439;>Green Alert</span> ==
The normal operating procedure. ''There is no currently known threat to the ship, nor crew.''

{| class="wikitable" style="width: 80%; border: 1px solid #000000;"
!style="text-align:left; width:25%; padding:5px; padding-left:10px; background-color:#4f8439BF; border: 1px solid #000000;" | '''Condition'''
!style="text-align:left; width:75%; padding:5px; padding-left:10px; background-color:#4f8439BF; border: 1px solid #000000;" | '''Description'''
|-
| style="border: 1px solid #000000;" | Chain of Command
| style="border: 1px solid #000000;" | [[Standard_Operating_Procedure#Captain’s_Authority|CO]] > Department Heads > Supervisory Roles
|-
| style="border: 1px solid #000000;" | Armoury Policy
| style="border: 1px solid #000000;" | Open carrying of long arms disallowed for Security personnel. Standard stab-and bullet-resistant equipment recommended for Security personnel.
|-
| style="border: 1px solid #000000;" | Discipline
| style="border: 1px solid #000000;" | Report to supervisor for general orders.
|-
| style="border: 1px solid #000000;" | Secure Areas
| style="border: 1px solid #000000;" | Secure areas unbolted and accessible to all authorized personnel. HSAs and areas with an expectation of privacy, such as bedrooms, dorms, or medical treatment facilities, may be bolted as needed.
|-
| style="border: 1px solid #000000;" | Medical
| style="border: 1px solid #000000;" | Binary suit sensors recommended at a minimum.
|-
| style="border: 1px solid #000000;" | Engineering
| style="border: 1px solid #000000;" | Report to supervisor for general orders.
|-
| style="border: 1px solid #000000;" | Rules of Engagement
| style="border: 1px solid #000000;" | Engage with minimal force required; prioritize de-escalation whenever possible.
|}

== <span style="color:#416db7;>Blue Alert</span> ==
Elevated alert status. ''There is an ongoing, known, or suspected security threat to the NanoTrasen vessel or its crew, or another significant security emergency.''

{| class="wikitable" style="width: 80%; border: 1px solid #000000;"
!style="text-align:left; width:25%; padding:5px; padding-left:10px; background-color:#416db7BF; border: 1px solid #000000;" | '''Condition'''
!style="text-align:left; width:75%; padding:5px; padding-left:10px; background-color:#416db7BF; border: 1px solid #000000;" | '''Description'''
|-
| style="border: 1px solid #000000;" | Chain of Command
| style="border: 1px solid #000000;" | [[Standard_Operating_Procedure#Captain’s_Authority|CO]] > [[Head of Security|Head of Station Security]] > Department Heads > Supervisory Roles
|-
| style="border: 1px solid #000000;" | Armoury Policy
| style="border: 1px solid #000000;" | Open carry of weaponry permitted for all authorised entities. Body armour mandatory for Security personnel.
|-
| style="border: 1px solid #000000;" | Discipline
| style="border: 1px solid #000000;" | Report to supervisor for general orders. Searching individuals suspected of committing a crime is encouraged.
|-
| style="border: 1px solid #000000;" | Secure Areas
| style="border: 1px solid #000000;" | Secure areas unbolted unless affected by known threats. Bolting [[Standard_Operating_Procedure#High_Security_Areas|HSAs]] recommended.
|-
| style="border: 1px solid #000000;" | Medical
| style="border: 1px solid #000000;" | Binary suit sensors recommended at a minimum. EVA suits recommended for emergency responders, functioning internals and PPE heavily advised.
|-
| style="border: 1px solid #000000;" | Engineering
| style="border: 1px solid #000000;" | EVA suits recommended for engineers.
|-
| style="border: 1px solid #000000;" | Rules of Engagement
| style="border: 1px solid #000000;" | Engage with minimal force required; non-lethal weapons may be used freely based on threat and compliance.
|}

== <span style="color:#a43e3e;>Red Alert</span> ==
Emergency alert status. ''There are multiple major emergency situations ongoing, or a major security emergency affecting the station.''

{| class="wikitable" style="width: 80%; border: 1px solid #000000;"
!style="text-align:left; width:25%; padding:5px; padding-left:10px; background-color:#a43e3eBF; border: 1px solid #000000;" | '''Condition'''
!style="text-align:left; width:75%; padding:5px; padding-left:10px; background-color:#a43e3eBF; border: 1px solid #000000;" | '''Description'''
|-
| style="border: 1px solid #000000;" | Chain of Command
| style="border: 1px solid #000000;" | [[Standard_Operating_Procedure#Captain’s_Authority|CO]] > Security Personnel > Department Heads > Supervisory Roles
|-
| style="border: 1px solid #000000;" | Armoury Policy
| style="border: 1px solid #000000;" | Issuing of lethal weapons heavily recommended. Body armour and helmets mandatory for Security personnel.
|-
| style="border: 1px solid #000000;" | Discipline
| style="border: 1px solid #000000;" | Report to supervisor for general orders. Protection of personnel prioritized over body and department searches.
|-
| style="border: 1px solid #000000;" | Secure Areas
| style="border: 1px solid #000000;" | All [[Standard_Operating_Procedure#High_Security_Areas|HSAs]] recommended to be bolted and under guard. Secure areas unbolted unless affected by known threats.
|-
| style="border: 1px solid #000000;" | Medical
| style="border: 1px solid #000000;" | Full suit sensors heavily advised. EVA suits and functioning internals heavily advised for emergency responders.
|-
| style="border: 1px solid #000000;" | Engineering
| style="border: 1px solid #000000;" | EVA suits heavily advised for engineers. Make emergency internals easily accessible.
|-
| style="border: 1px solid #000000;" | Rules of Engagement
| style="border: 1px solid #000000;" | Engage with adequate force to safely subdue suspects, dependent on threat and compliance. Lethal force is permitted to effect arrests against evasive targets.
|}

== <span style="color:#583ca2;>Violet Alert</span> ==
Elevated alert status. ''There is a serious viral outbreak, ongoing major death event, or there is another significant medical emergency.''

{| class="wikitable" style="width: 80%; border: 1px solid #000000;"
!style="text-align:left; width:25%; padding:5px; padding-left:10px; background-color:#583ca2BF; border: 1px solid #000000;" | '''Condition'''
!style="text-align:left; width:75%; padding:5px; padding-left:10px; background-color:#583ca2BF; border: 1px solid #000000;" | '''Description'''
|-
| style="border: 1px solid #000000;" | Chain of Command
| style="border: 1px solid #000000;" | [[Standard_Operating_Procedure#Captain’s_Authority|CO]] > [[Chief Medical Officer]] > Medical Personnel > Department Heads > Supervisory Roles
|-
| style="border: 1px solid #000000;" | Armoury Policy
| style="border: 1px solid #000000;" | Issuing of lethal weapons disadvised. Standard stab-and bullet-resistant equipment recommended for Security personnel. Biohazard gear advised.
|-
| style="border: 1px solid #000000;" | Discipline
| style="border: 1px solid #000000;" | Report to supervisor for orders. Non-medical personnel should ensure they do not interfere with medical staff. Security should seek to aid medical staff where possible.
|-
| style="border: 1px solid #000000;" | Secure Areas
| style="border: 1px solid #000000;" | Secure areas unbolted. [[Standard_Operating_Procedure#High_Security_Areas|HSAs]] and areas with an expectation of privacy, such as bedrooms, dorms, or medical treatment facilities, may be bolted as needed.
|-
| style="border: 1px solid #000000;" | Medical
| style="border: 1px solid #000000;" | Report to supervisor for orders. Full suit sensors heavily advised. EVA suits recommended for emergency responders, functioning internals and PPE heavily advised.
|-
| style="border: 1px solid #000000;" | Engineering
| style="border: 1px solid #000000;" | Report to supervisor for general orders.
|-
| style="border: 1px solid #000000;" | Rules of Engagement
| style="border: 1px solid #000000;" | Engage with minimal force required; prioritize de-escalation whenever possible.
|}

== <span style="color:#999933;>Yellow Alert</span> ==
Elevated alert status. ''There is a major issue with the atmospheric system, the station has suffered/is about to suffer significant damage, or there is another significant engineering emergency.''

{| class="wikitable" style="width: 80%; border: 1px solid #000000;"
!style="text-align:left; width:25%; padding:5px; padding-left:10px; background-color:#999933BF; border: 1px solid #000000;" | '''Condition'''
!style="text-align:left; width:75%; padding:5px; padding-left:10px; background-color:#999933BF; border: 1px solid #000000;" | '''Description'''
|-
| style="border: 1px solid #000000;" | Chain of Command
| style="border: 1px solid #000000;" | [[Standard_Operating_Procedure#Captain’s_Authority|CO]] > [[Chief Engineer]] > Engineering Personnel > Department Heads > Supervisory Roles
|-
| style="border: 1px solid #000000;" | Armoury Policy
| style="border: 1px solid #000000;" | Issuing of lethal weapons disadvised. EVA protection heavily advised for all personnel.
|-
| style="border: 1px solid #000000;" | Discipline
| style="border: 1px solid #000000;" | Report to supervisor for orders. Non-engineering personnel advised to evacuate affected areas. Security should seek to aid engineering staff where possible.
|-
| style="border: 1px solid #000000;" | Secure Areas
| style="border: 1px solid #000000;" | Secure areas unbolted. [[Standard_Operating_Procedure#High_Security_Areas|HSAs]] and areas with an expectation of privacy, such as bedrooms, dorms, or medical treatment facilities, may be bolted as needed.
|-
| style="border: 1px solid #000000;" | Medical
| style="border: 1px solid #000000;" | Full suit sensors heavily advised. EVA suits and functioning internals recommended for emergency responders.
|-
| style="border: 1px solid #000000;" | Engineering
| style="border: 1px solid #000000;" | EVA suits heavily advised for engineers. Distribute emergency internals to crew. Propose evacuation if damage is irreparable or sufficiently hazardous.
|-
| style="border: 1px solid #000000;" | Rules of Engagement
| style="border: 1px solid #000000;" | Engage with minimal force required; prioritize de-escalation whenever possible.
|}

== White Alert ==
Elevated alert status. ''The station is suffering dangerously high levels of glimmer, there are several active psionic threats, or there is another significant epistemic emergency.''

{| class="wikitable" style="width: 80%; border: 1px solid #000000;"
!style="text-align:left; width:25%; padding:5px; padding-left:10px; background-color:#a6a6a6BF; border: 1px solid #000000;" | '''Condition'''
!style="text-align:left; width:75%; padding:5px; padding-left:10px; background-color:#a6a6a6BF; border: 1px solid #000000;" | '''Description'''
|-
| style="border: 1px solid #000000;" | Chain of Command
| style="border: 1px solid #000000;" | [[Standard_Operating_Procedure#Captain’s_Authority|CO]] > [[Mystagogue]] > Epistemics Personnel > Department Heads > Supervisory Roles
|-
| style="border: 1px solid #000000;" | Armoury Policy
| style="border: 1px solid #000000;" | Psionic insulation recommended for all personnel. Open carry of weaponry permitted for authorised entities. Standard stab- and bullet-resistant equipment recommended for Security personnel.
|-
| style="border: 1px solid #000000;" | Discipline
| style="border: 1px solid #000000;" | Report to supervisor for orders. Security and Engineering should seek to aid epistemics staff where possible. Propose evacuation if glimmer spiral is unrecoverable.
|-
| style="border: 1px solid #000000;" | Secure Areas
| style="border: 1px solid #000000;" | Secure areas unbolted. [[Standard_Operating_Procedure#High_Security_Areas|HSAs]] and areas with an expectation of privacy, such as bedrooms, dorms, or medical treatment facilities, may be bolted as needed.
|-
| style="border: 1px solid #000000;" | Medical
| style="border: 1px solid #000000;" | Full suit sensors heavily advised. Prepare for increased incidents of burn and brain damage.
|-
| style="border: 1px solid #000000;" | Engineering
| style="border: 1px solid #000000;" | EVA suits heavily advised for engineers. Distribute emergency internals to crew. Prepare for detonation of [[Glimmer#Probers|probers]].
|-
| style="border: 1px solid #000000;" | Rules of Engagement
| style="border: 1px solid #000000;" | Engage with minimal force required; ROE on mindwiping is lifted and may be performed by the Psionic Mantis, Chaplain or Mystagogue at their discretion.
|}

== <span style="color:#36717d;>Gamma Alert</span> ==
Emergency alert status. ''Central Command has called the Gamma Alert; the Station is on its last legs, almost everyone is dead, or there is another existential crisis affecting the station.''

{| class="wikitable" style="width: 80%; border: 1px solid #000000;"
!style="text-align:left; width:25%; padding:5px; padding-left:10px; background-color:#36717dBF; border: 1px solid #000000;" | '''Condition'''
!style="text-align:left; width:75%; padding:5px; padding-left:10px; background-color:#36717dBF; border: 1px solid #000000;" | '''Description'''
|-
| style="border: 1px solid #000000;" | Chain of Command
| style="border: 1px solid #000000;" | [[Standard_Operating_Procedure#Captain’s_Authority|CO]] > Security Personnel > Department Heads > Supervisory Roles
|-
| style="border: 1px solid #000000;" | Armoury Policy
| style="border: 1px solid #000000;" | Issuing of lethal weapons heavily recommended. Body armour and helmets mandatory for Security personnel. EVA protection heavily advised for all personnel.
|-
| style="border: 1px solid #000000;" | Discipline
| style="border: 1px solid #000000;" | Report to supervisor for general orders. Martial law is in effect.
|-
| style="border: 1px solid #000000;" | Secure Areas
| style="border: 1px solid #000000;" | All [[Standard_Operating_Procedure#High_Security_Areas|HSAs]] recommended to be bolted and under guard. Secure areas unbolted.
|-
| style="border: 1px solid #000000;" | Medical
| style="border: 1px solid #000000;" | Full suit sensors mandatory for observation and safety. EVA suits and functioning internals heavily advised for emergency responders.
|-
| style="border: 1px solid #000000;" | Engineering
| style="border: 1px solid #000000;" | EVA suits heavily advised for engineers. Distribute emergency internals to crew.
|-
| style="border: 1px solid #000000;" | Rules of Engagement
| style="border: 1px solid #000000;" | Martial law is in effect.
|}

== <span style="color:#996633;>Delta Alert</span> ==
Emergency alert status. ''The nuclear destruction mechanism has been engaged and station destruction is imminent. All crew aboard the station must attempt to reverse the self-destruct mechanism, if engaged in error. Should reversal prove impossible, evacuate as applicable.
''

{| class="wikitable" style="width: 80%; border: 1px solid #000000;"
!style="text-align:left; width:25%; padding:5px; padding-left:10px; background-color:#996633BF; border: 1px solid #000000;" | '''Condition'''
!style="text-align:left; width:75%; padding:5px; padding-left:10px; background-color:#996633BF; border: 1px solid #000000;" | '''Description'''
|-
| style="border: 1px solid #000000;" | Chain of Command
| style="border: 1px solid #000000;" | [[Standard_Operating_Procedure#Captain’s_Authority|CO]] > Security Personnel > Department Heads > Supervisory Roles
|-
| style="border: 1px solid #000000;" | Armoury Policy
| style="border: 1px solid #000000;" | Issuing of lethal weapons heavily recommended. Body armour and helmets mandatory for Security personnel. EVA protection heavily advised for all personnel.
|-
| style="border: 1px solid #000000;" | Discipline
| style="border: 1px solid #000000;" | Security and Command must expend all efforts to prevent station destruction if engaged in error. Martial law is in effect.
|-
| style="border: 1px solid #000000;" | Secure Areas
| style="border: 1px solid #000000;" | All secure areas and [[Standard_Operating_Procedure#High_Security_Areas|HSAs]] should remain unbolted.
|-
| style="border: 1px solid #000000;" | Medical
| style="border: 1px solid #000000;" | Full suit sensors mandatory for observation and safety. EVA suits and functioning internals heavily advised for emergency responders.
|-
| style="border: 1px solid #000000;" | Engineering
| style="border: 1px solid #000000;" | EVA suits heavily advised for engineers. Distribute emergency internals to crew.
|-
| style="border: 1px solid #000000;" | Rules of Engagement
| style="border: 1px solid #000000;" | Martial law is in effect.
|}

== <span style="color:#cae8e8;>Code Octarine</span> ==
Emergency alert status''. The station's deep-spectrum sensors have identified critical Λ-CDM levels. The station and all surrounding space is under threat of an impending existential noospheric-to-real threat.''

{| class="wikitable" style="width: 80%; border: 1px solid #000000;"
!style="text-align:left; width:25%; padding:5px; padding-left:10px; background-color:#583ca2BF; border: 1px solid #000000;" | '''Condition'''
!style="text-align:left; width:75%; padding:5px; padding-left:10px; background-color:#583ca2BF; border: 1px solid #000000;" | '''Description'''
|-
| style="border: 1px solid #000000;" | Chain of Command
| style="border: 1px solid #000000;" | [[Standard_Operating_Procedure#Captain’s_Authority|CO]] > [[Mystagogue]] > Security Personnel > Department Heads > Supervisory Roles >
|-
| style="border: 1px solid #000000;" | Armoury Policy
| style="border: 1px solid #000000;" | Issuing of lethal weapons recommended. Body armour and helmets mandatory for Security personnel, permitted for distribution to authorised personnel. EVA protection strongly advised for all personnel.
|-
| style="border: 1px solid #000000;" | Discipline
| style="border: 1px solid #000000;" | Emergency personnel must expend all efforts to prevent station destruction. Arrests, searches, and raids may be performed at the discretion of security personnel and without a warrant. Where possible, threats should be subdued and brought to the Chaplain or Mystagogue for processing.
|-
| style="border: 1px solid #000000;" | Secure Areas
| style="border: 1px solid #000000;" | All secure areas and [[Standard_Operating_Procedure#High_Security_Areas|HSAs]] should remain unbolted.
|-
| style="border: 1px solid #000000;" | Medical
| style="border: 1px solid #000000;" | Full suit sensors mandatory for observation and safety. EVA suits and functioning internals heavily advised for emergency responders.
|-
| style="border: 1px solid #000000;" | Engineering
| style="border: 1px solid #000000;" | EVA suits heavily advised for engineers. Distribute emergency internals to crew.
|-
| style="border: 1px solid #000000;" | Rules of Engagement
| style="border: 1px solid #000000;" | Engage with adequate force to neutralise threats. Lethal force authorised at the discretion of Security personnel, in self-defence, or to effect arrests. ROE on mindwiping is lifted and may be performed by the Psionic Mantis or Mystagogue at their discretion.
|}

== <span style="color:#b000ff;>Code Epsilon</span> ==
Emergency alert status. ''Central Command has ordered the Epsilon security level on the station. Only orders from Central Command Officials are to be obeyed by the Station's Crew. Martial Law is in effect.''

{| class="wikitable" style="width: 80%; border: 1px solid #000000;"
!style="text-align:left; width:25%; padding:5px; padding-left:10px; background-color:#b000ffFF; border: 1px solid #000000;" | '''Condition'''
!style="text-align:left; width:75%; padding:5px; padding-left:10px; background-color:#b000ffFF; border: 1px solid #000000;" | '''Description'''
|-
| style="border: 1px solid #000000;" | Chain of Command
| style="border: 1px solid #000000;" | Central Command
|-
| style="border: 1px solid #000000;" | Armoury Policy
| style="border: 1px solid #000000;" | Await orders from Central Command Personnel.
|-
| style="border: 1px solid #000000;" | Discipline
| style="border: 1px solid #000000;" | Await orders from Central Command Personnel.
|-
| style="border: 1px solid #000000;" | Secure Areas
| style="border: 1px solid #000000;" | Await orders from Central Command Personnel.
|-
| style="border: 1px solid #000000;" | Medical
| style="border: 1px solid #000000;" | Full suit sensors mandatory for observation and safety. Await orders from Central Command Personnel.
|-
| style="border: 1px solid #000000;" | Engineering
| style="border: 1px solid #000000;" | Await orders from Central Command Personnel.
|-
| style="border: 1px solid #000000;" | Rules of Engagement
| style="border: 1px solid #000000;" | Martial Law is in effect. Do not engage with Central Command Personnel. Await orders from Central Command Personnel.
|}

{{Guides Menu}}

Event Policy

2026-05-16T20:09:35Z

Vape:

''This policy refers to Administrators and Curators, Unless otherwise specified.''

1. '''Actions of Staff during round must be reported to the #Event-log in discord.''' <small>This includes all “One-off” spawns. Spawns and actions pertaining to an approved event can be skipped as long as the event itself has been reported. Major changes to an event in-round must be logged. This excludes small actions that are taken to preserve the integrity of the game, such as moving players & addressing small bugs.</small>

2. '''<span style="color:red;">Never''' '''use a “smite” against a player character that is in round.''' <small>This includes possible raiders. Smites have the capacity to be irreversible and game breaking. They should not be used outside of the admin arena.</small>

3. '''Events should be allowed to play out at their own pace.''' <small>Events will almost invariably be affected by the crew, antagonists, or natural occurrences within the round; let the round flow organically and allow players to interact with the event rather than forcing them to follow a script. Let them fail if needed.
</small>

4. '''Events must meet or exceed our MRP Standard.''' <small>Both the rationale and implementation of an event must demonstrate evidence of a story, or be beneficial to the story unfolding on the station currently.</small>

5. '''Events must not feature staff-level ghost roles such as deathsquad unless directly authorized by a Head of Staff.''' <small>These roles should be filled by staff and represent both Administration and Curation in an in-character fashion.</small>

6. '''Events should never portray ''<span style="color:cyan;">NanoTrasen'' or ''<span style="color:green;">Central Command'' as directly antagonistic to the crew.''' <small>While Central Command is expected to be strict - especially on matters of policy and procedure - they should be supportive where possible, politely evasive when pressed, and only authoritative in extreme circumstances.</small>

7. '''Events should not disrupt the balance of the round.''' <small>Don't introduce overpowered, unique, or usually unobtainable ghost roles, entities, or items, and should not overwhelm the round, the station, or its resources. This includes objective items, spawn-only items, leviathings, etc.</small>

8. '''Event roles should be reserved for players.''' <small>Staff are expected to organize and oversee the event, not partake in it. If a ghost role is not taken for '''<span style="color:yellow;">more than 5 minutes''', the eventing staff member may join the queue .</small>

9. '''aGhosts are welcome to take any ghost roles.''' <small>Refer to the previous rule regarding roles you have spawned.</small>

10. '''Do not test unknown commands on the game servers.''' <small>All testing of Console commands, VVwrites, and other “Unused” aGhost powers should take place on a personal dev environment, not on the game servers.</small>

11. '''You may not take ERT Leadership roles unless 5 minutes has passed without anyone taking the role.'''

12. '''Any spawned CC character going to the station, must be armed by security on station.''' <small><span style="color:red;">If your character is visiting the station or leaving CC in any capacity, You are not allowed to spawn weapons for them.</small>

= Event Categories =

* '''<span style="color:green;">Low Impact''' - <small>These events may be run by</small> '''<span style="color:green;">Trial-Game Administrators''' / '''<span style="color:orange;">Trial-Curators''' <small>or above without approval.</small>
Low impact events either:
* Do not interact with players in a meaningful way
* Are a direct response to a player request or interaction, and do not affect the round to a greater degree
-> Such as responding to faxes or answering prayers

* '''<span style="color:yellow;">Medium Impact''' - <small>These events may be run by</small> '''<span style="color:green;">Trial-Game Administrators''' / '''<span style="color:orange;">Trial-Curators''' <small>with approval from a second (non-trial) Staff member.</small> '''<span style="color:green;">Senior Administrators''' / '''<span style="color:orange;">Senior Curators''' <small>and above do not need approval.</small>
Medium impact events either
* Considerable affect players or the round without derailing the round, round-removing
players, or taking significant resources and manpower from departments.
* Add a new gamerule unlikely to cause significant effect on players or the round
* Are a direct response to a player request or interaction that affects the round to a considerable degree.
-> Such as adding a Clown Spider spawn or adding a single round ending antag

* '''<span style="color:red;">High Impact''' - <small>These events may be run following the mandatory notice (when applicable) and when approved by a</small> '''<span style="color:orange;">Senior Curator''' / '''<span style="color:green;">Senior Administrator''' <small>or above.</small>
High impact events either:
* Heavily affect players or the round, possibly derailing the round, round-removing
players, or taking significant resources and manpower from departments
* Add a new gamemode, causing significant effect on players or the round
* Are a direct response to a player request or interaction that results in a High Impact event.
-> Some Examples include setting the game mode or spawning multiple round ending antagonists

⚠️'''<span style="color:red;">High impact events must be planned, written in Directions event library, and approved. Additionally, a mandatory two hour notice must be posted in the event log prior to running these events, unless otherwise authorised by at least a Senior Administrator, Senior Curator, or Head of Staff. An event plan should include entity/role requirements, event goals, players and departments involved, and “Staffing” needs.'''⚠️

== Exceptions to event policy ==

1. '''Staff are permitted to spawn in Central Command characters for the purpose of greeting crew or writing faxes.''' <small>CC Characters should be competent, reasonably named, and disconnected from any “In-game” characters.</small>

2. '''Staff are permitted to create ghost bars.''' <small>Spawning ghost roles on a separate map from the station for the purpose of a gag, sandbox construction, ETC</small>

3. '''Staff are permitted to remodel “Midpoint” to reflect events that occurred during the round, and to remodel “Midpoint” to reflect a more artistic and “Destressed” environment for players to end their round.''' <small>The latter requires appropriate documentation in the Event-log, and following “Medium-Impact” approval</small>

4. '''Staff are permitted to Spawn ERT following the chart listed below.''' <small><span style="color:red;">Any exceptions require approval from a Senior Administrator/Senior Curator or above.</small>

[[File:ERT chart.jpg|thumb]]

= Epsilon Procedure =

<span style="color:red;">''In the event that Epsilon is or will be needed, Permission is required by a <span style="color:orange;">HEAD OF STAFF or SENIOR CURATOR. <span style="color:red;">If either of these options are unavailable, the agreement of <span style="color:orange;">2 Non-Trial Curators or Admins <span style="color:red;">can pass this only <span style="color:orange;">after 10 minutes without answer''

Content Removal

2026-05-08T16:54:49Z

Vape:

'''<big>Content Removal Policy</big>'''

In order to achieve our design visions and maintain the “state of the game” some content will inevitably have to be replaced or removed. The preference is to replace content that does not meet our standards with improved content wherever possible.

Test Merges are exempt from the Content Removal Policy, and can be removed at anytime by a standard Content “Review”.

=== '''In order to remove content, You must:''' ===

* Make a list of issues with the content

*Announce the planned removal of the content, including a date, and its issues - <small>For classifications of "Major Content" only</small>

*Create a community feedback post regarding the removal, the issues, and a specific date of removal.

* Establish a deadline for action (Removal or Replacement)

=== Appropriate Deadlines: ===

* 1 week - minor to moderate content (Sprites, Mechanical balances, Items, Machines, Etc)

* 2 weeks - Major content (Gamemodes, Roles, Multiple minor/moderate content items as a "bundle"** Etc)

Content that is extremely broken or severely detrimental to the game experience may be removed '''without''' this process

If Community feedback for removal is overwhelmingly negative, Content Review is required to seek approval of both the Content Director and the Project Management Team before finalizing removal.

Content removal at an authors request will be '''considered''' and ''should require a valid reason, such as balance concerns, server stability concerns, or lack of implementation (e.g. not finished).'' The Content Director and Maintainers will have final say on removal via author request, due to content direction and feasibility of removal respectively. ''Content that has been worked on by multiple contributors (E.g. Spritework + Code) will only be removed when all parties that contributed request removal.''

<nowiki>**</nowiki> Bundles are considered any content that includes more than 1 item. Some examples include superweapons or the improvised armory. Bundles do not include items that require specific parts to function, such as "blunderbuss" and "Blunderbuss ammo", as an example.

Content Removal

2026-05-08T16:54:17Z

Vape:

Content Removal

2026-05-08T16:49:17Z

Vape:

'''<big>Content Removal Policy</big>'''

In order to achieve our design visions and maintain the “state of the game” some content will inevitably have to be replaced or removed. The preference is to replace content that does not meet our standards with improved content wherever possible.

Test Merges are exempt from the Content Removal Policy, and can be removed at anytime by a standard Content “Review”.

=== '''In order to remove content, You must:''' ===

* Make a list of issues with the content

*Announce the planned removal of the content, including a date, and its issues - <small>For classifications of "Major Content" only</small>

*Create a community feedback post regarding the removal, the issues, and a specific date of removal.

* Establish a deadline for action (Removal or Replacement)

=== Appropriate Deadlines: ===

* 1 week - minor to moderate content (Sprites, Mechanical balances, Items, Machines, Etc)

* 2 weeks - Major content (Gamemodes, Roles, Multiple minor/moderate content items as a "bundle" Etc)

Content that is extremely broken or severely detrimental to the game experience may be removed '''without''' this process.

If Community feedback for removal is overwhelmingly negative, Content Review is required to seek approval of both the Content Director and the Project Management Team before finalizing removal.

Content removal at an authors request will be '''considered''' and ''should require a valid reason, such as balance concerns, server stability concerns, or lack of implementation (e.g. not finished).'' The Content Director and Maintainers will have final say on removal via author request, due to content direction and feasibility of removal respectively. ''Content that has been worked on by multiple contributors (E.g. Spritework + Code) will only be removed when all parties that contributed request removal.''

Content Removal

2026-05-08T16:15:54Z

Vape: Requested Changes to policy

'''<big>Content Removal Policy</big>'''

In order to achieve our design visions and maintain the “state of the game” some content will inevitably have to be replaced or removed. The preference is to replace content that does not meet our standards with improved content wherever possible.

Test Merges are exempt from the Content Removal Policy, and can be removed at anytime by a standard Content “Review”.

=== '''In order to remove content, You must:''' ===

* Make a list of issues with the content

*Announce the planned removal of the content, including a date, and its issues - <small>For classifications of "Major Content" only, see below</small>

*Create a community feedback post regarding the removal, the issues, and a specific date of removal.

* Establish a deadline for action (Removal or Replacement)

=== Appropriate Deadlines: ===

* 1 week - minor to moderate content (Sprites, Mechanical balances, Items, Machines, Etc)

* 2 weeks - Major content (Gamemodes, Roles, Multiple minor/moderate content items as a "bundle" Etc)

Content that is extremely broken or severely detrimental to the game experience may be removed '''without''' this process.

If Community feedback for removal is overwhelmingly negative, Content Review is required to seek approval of both the Content Director and the Project Management Team before finalizing removal.

Content removal at an authors request will be '''considered''' and ''should require a valid reason, such as balance concerns, server stability concerns, or lack of implementation (e.g. not finished).'' The Content Director and Maintainers will have final say on removal via author request, due to content direction and feasibility of removal respectively. ''Content that has been worked on by multiple contributors (E.g. Spritework + Code) will only be removed when all parties that contributed request removal.''

SESD TBD

2026-05-05T15:44:15Z

Vape: Created page with "== Senior Staff Guidelines == Senior Staff generally are encouraged to assist heads by performing assigned tasks. This document has been made to list out some of those tasks that are "Regular Occurrences" and the expectations of what Senior level staff are expected to do / Perform. This document, while official, is subject to change at any time with the request of the direct head of staffs request. Senior Staff are expected to understand what they are empowered to perfor..."

== Senior Staff Guidelines ==
Senior Staff generally are encouraged to assist heads by performing assigned tasks. This document has been made to list out some of those tasks that are "Regular Occurrences" and the expectations of what Senior level staff are expected to do / Perform. This document, while official, is subject to change at any time with the request of the direct head of staffs request. Senior Staff are expected to understand what they are empowered to perform, and what should be taken to a head.

=== Senior Content Review ===
Senior Content Reviewers are expected to:

* Ensure Reviews are performed in a timely manner
* Be knowledgeable on the Review Policy, and at times, encourage reviewers to stick to this policy
* Make decisions regarding the need for a review
* Make decisions regarding Test Merges
* Assist the Content Director with any additional tasks that are needed / requested
* Assist in continuance of training regarding new reviewers, and should be capable of explaining "How To" perform the daily tasks of a Content Reviewer

Should a scenario occur where policy is not being followed, and a simple encouragement does not suffice, Seniors are expected to report this to the Content Director, without taking this into their own hands.

=== Senior Moderation ===
Senior Moderators are expected to:

* Perform in-depth investigations into Mhelps
* Perform in-depth investigations into staff reports that are relevant to their accesses
* Assist the Head Moderator in ongoing investigations that their access allows
* Educate and Guide new moderators with Mod Policy
* Should be capable of stepping into a ticket should a Mod become overwhelmed or overstepped

Should a scenario occur where policy is not being followed, and a simple encouragement does not suffice, Seniors are expected to report this to the Head Moderator, without taking this into their own hands.

=== Senior Administration ===
Senior Administrators are expected to:

* Provide Guidance on rulings that are complex to Admins
* Refer to previous rulings on similar situations, and make similar rulings as needed
* Understand how to perform Log Diving investigations, and be capable of teaching this to Trials and Game admins
* Be knowledgeable in the rules, and capable of identifying what rules have been broken
* Encourage Game admins and Trials to follow rulings, and to not intervene in situations that should be handled "In Character"
* Be capable in defusing a situation, whether this is between staff or players
* Should be capable of stepping into a ticket should an Admin become overwhelmed or overstepped
* Regularly check Senior Admin Channels and forums for important information and changing dynamics as informed by the headmins.

Should a scenario occur where policy is not being followed, and a simple encouragement does not suffice, Seniors are expected to report this to the Head Administrator, without taking this into their own hands. Should a scenario occur where a clear violation of Admin Policy is in order, Senior Admins are suggested to form a Staff report with relevant information.

=== Senior Curators / Eventers ===

Xenoarcheology

2026-05-05T01:41:47Z

Vape:

{{Needs revision
|reason=Information may still need photos, and still needs information regarding artifacts.
|image=RebaseWork.png
}}
Xenoarcheology is a method of point generation for [[Research_and_Development|R&D]] utilizing randomly generated artifacts. It is the job of [[Scientist|scientists]] to discover and activate the secrets of these artifacts.

__TOC__

== Equipment ==
The actual experimentation of artifacts uses a variety of equipment that can be found scattered around the station. This specifically focuses on the specific items used and contained within the xenoarcheology lab.

[[File:Analysis-console-ui.png|thumb|400px|''The analysis console ui before a scan.'']]
=== Analysis Console ===

[[File:Analysis Console.gif|64px]]

The analysis console is the main method of getting information about the artifacts that are being researched. In order to properly use it, it must be linked to an artifact analyzer via multitool as well as have a research server selected.

From the console itself, the screen displays information about the last artifact scanned. The buttons along the side perform various functions:

{| class="wikitable"
|-
! Button Name !! Description
|-
| Server List || Opens a menu for selecting a research server.
|-
| Extract || Extracts the research points from the artifact. The amount of points is based on how many nodes have been activated and will increase the glimmer count.
|}

=== Artifact Analyzer ===
[[File:Analyzer-full.png|64px]]

The artifact analyzer is a machine used in conjunction with the analysis console to scan artifacts to discover information about them. Artifacts are scanned by placing them on this machine at which point will show you information regarding tbe artifact.

=== Node Scanner ===
[[File:Node Scanner.png|64px]]

The archaeologist's friend. It's able to identify the node ID of the artifact.

== Artifacts ==
[[File:Artifact-lineup.png|448px]]

Artifacts are the core of Xenoarcheology and are what scientists will be analyzing and experimenting on. Artifacts can take on a variety of random appearances and can be acquired in various ways, such as through finding them in the lab at the start of the round, purchasing them from [[Cargo Technician|Logistics]], getting them from [[Salvage Specialist|Salvage]], or finding them from the Bluespace Anomaly station event.

Artifacts consist of randomly generated "trees" which dictates the artifacts behavior. Each tree consists of various "nodes" which the artifact can be inside of. Nodes each contain a "trigger" and an "effect". Effects can be both passive, constantly occurring and active, happening only once. To progress "up" to the next node in a tree, all other nodes below it must be completed. You will know a node is completed when the node is purple and the effect listed has gone off.

Some nodes will have multiple Stimulus in order to react, you must complete all required Stimulus in order to get the artifact to react and for the node to complete. You will have a set amount of time to complete all stimuli listed by the analysis console.

The activation of the various nodes is the main goal of Xenoarcheology. Unlocking the nodes of an artifact increases its value, both in research points and in spacebucks.

== Analysis Interpretation ==
[[File:Analysis-console-scan.png]]

Each scan of the artifact analyzer gives various data about the artifact:
{| class="wikitable"
|-
! In-Game Phrase !! Meaning !! Description
|-
| NODE_ID || ID || A unique ID number corresponding to each node. Can be used for identification.
|-
| DEPTH || Node tree depth || The distance from the starting node of the tree. Higher depths correspond to more dangerous and harder to activate artifacts which in turn increase the value when discovered.
|-
| ACTIVATED || Activation || Whether or not the "trigger" for the node has been activated.
|-
| STIMULUS || Trigger || A hint about the specific trigger for this node. Usually gives a good idea about what activates the artifact.
|-
| REACTION || Effect || A hint about the effect for this node. Usually is vague and non-specific.
|-
| EDGES || Neighboring nodes || The number of nodes that are adjacent to the current node minus one meaning if you have an artifact with 3 edges it has 2 possible paths on Delta V. Other servers do not have this quirk.
|-
| CURRENT_VALUE || Point value || The number of research points that the artifact will give if extracted.
|}

It is important to note that each scan functions as a static snapshot of the current node. It does not update with the artifact and will only update when scanned again.

=== Stimulus ===
Some of the given hints for triggering an artifact are used for different scenarios, see Physical trauma which can vary from hugging it to attacking it. Things that deal with atmospheric changes, radiation, or beating the artifacts butt can scale with the depth so don't give up if it seems to not do much

* Therapeutic Chemicals:
** Use a space medi-pen on a beaker and splash the artifact with it.

* '''Electricity:'''
*:*Touch it with a [[File:Multitool.png]] multi-tool.
*:*Have the artifact receive 500 power from a Medium Voltage cable.

* '''High temperatures:'''
*:*Hot items: Use a [[File:Lighter.png]] lighter, [[File:Welder.png]] welder or similar items with flames on the artefact.
*:*High temperatures: Place the artifact in a room that is more than 373 kelvin degrees.

* '''Physical trauma:'''
*:*Brute damage: Punch the artifact or hit it with a blunt object via [[Combat|Combat Mode]]. This may take several hits.
*:*Interaction: Touch or pull the artifact with your hands.
*:*High Damage: The artifact must receive 500 points of damage.

* '''Wrench'''
*:*While having a wrench [[File:Wrench.png]] in your hand click on the node to anchor the artifact to the ground.

* '''Screwing'''
*:*While having a screwdriver [[File:Screwdriver.png]] in your hand click on the node to screw the artifact.

* '''Prying'''
*:*While having a Crowbar [[File:Crowbar.png]] in your hand click on the node to pry the artifact.

* '''Pulsing'''
*:*While having a Multitool [[File:Multitool.png]] in your hand click on the node to pulse the artifact.

* '''Sonic vibrations:'''
*:*Play a musical instrument close to the artifact. You can also sing as a harpy to activate this.

* '''Hydro-reactive:'''
*:*Reacts to water! Spray water on it using a [[File:Spray Bottle.png]] spray bottle or [[File:Fire Extinguisher.png]] fire extinguisher.

* '''blood:'''
*:*Reacts to blood! Otherwise the same to Hydro-reactive.

* '''Magnetic waves:'''
*:*Magboots: Place magnetic boots [[File:Magboots.png]] next to the artifact, it will not work if you are holding or have them equipped you must drop them next to the artifact for it to work while they are activated.

* '''Death:'''
*:*Kill something near the artifact, like a mouse, or if you have the materials a cyborg works too.

* '''Radiation:'''
*:*The artifact must take at least 50 points of radiation damage and may scale depending on the depth.

* '''Extreme pressure:'''
*:*Low Pressure: Put the artifact in a room with less than 50 kPa pressure. Carry the artifact into space or space the room it is in. Most artifact chambers have an outlet to space, and if they don't, you can suck the air out with the pumps near it.
*:*High Pressure: Put the artifact in a room with more than 385 kPa pressure. You may want to contact an Atmosian to create a high pressure gas, or cause a plasma reaction.

* '''Standard atmospheric gases:'''
*:*Place the artifact in a room with Carbon Dioxide gas.

* '''Gaseous plasma:'''
*:*Place the Artifact in a room with Plasma gas.

* '''Active deceleration'''
*:*Throw the artifact. It must land on something.

* '''Examination:'''
*:*The artifact can activate every time you examine it (shift click).

* '''No Stimulus:'''
*:*Time based, it will have a chance to activate every 5 seconds.

=== Reaction ===
All the possible reactions of the artefact and what they might mean. 

* '''Cerebral influence''' :
*:*'''Instrument''': the artifact becomes an instrument of a random type.
*:*'''Mind Altering:''' the artifact will make you feel a certain way.

* '''Environmental disruption''' :
*:*'''Throw''': the artifact throws things close to it around the place, including tiles.
*:*'''Explosion''': the artifact generates an explosion that looks scarier than it is.
*:*'''Shatter''': the artifact has a 75% chance to give 200 {{DMG|Structural}} damage to every windows around it.
*:*'''Gas''': the artifact generates a random gas from: Plasma, Carbon Dioxide, Tritium, Miasma, Nitrous Oxide, Frezon.
*:*'''Heal''': The artifact heals 300 {{DMG|Brute}} and 300 {{DMG|Burn}} damage of nearby creatures.
*:*'''Boom''': The artifact generates a violent explosion (most common form of epi-boom seriously be careful if you see this)

* '''Electrical interference''' :
*:*'''Light''': The artifact makes the light flickers.
*:*'''Knock''': The artifact opens all nearby doors.
*:*'''EMP''': The artifact lets out a EMP wave draining and knocking out all nearby electrical devices.

* '''Metaphysical displacement ''':
*:*'''Movement''': The artifact starts randomly moving about the place.
*:*'''Blink''': The artifact teleports somewhere it has line of sight.
*:*'''Shuffle''': The artifact exchange people's place around by teleporting them.

* '''Matter creation''' :
*:*'''Junk''': Creates a bunch of various trash items.
*:*'''Banana''': Creates from 3 to 6 bananas in a puddle of Potassium.
*:*'''Instrument''': Creates up to 5 random instruments.
*:*'''Monkey''': Creates a [[Fauna#Monkey|monkey]] with a small chance of creating a [[Fauna#Gorilla|gorilla]].
*:*'''Ore''': Creates a maximum of 3 silver, plasma, gold and uranium ores each.
*:*'''Carp''': Creates up to 5 angry holocarps or magicarps.
*:*'''Cash''': Creates from 10 to 1750 spesos.
*:*'''Materials''': Creates up to 90 of either: Steel Sheets, Glass Sheets or Plastic Sheets
*:*'''Mitosis''': Creates another random artifact.
*:*'''Anomaly''': Creates a random anomaly.

* '''Energy consumption''' :
*:*'''Cold''': The artifact reduces the temperature in the room to 50 kelvin.

* '''Energy Release''' :
*:*'''Power''': The artifact becomes a power generator that generates 20kW.
*:*'''Heat''': The artifact makes the temperature in the room go to 500 kelvin.
*:*'''Battery''': The artifact recharges nearby batteries.
*:*'''Light Radiation''': The artifact becomes radioactive with an intensity of 2.
*:*'''Strong Radiation''': The artifact becomes radioactive with an intensity of 6.
*:*'''Ignite''': The artifact sets people near it on fire.

* '''Biochemical disruption''' :
*:*'''Chemical''': The artifact creates a random puddle of chemical.
*:*'''Foam''': The artifact generate a foam of a random chemical.
*:*'''Rare Chemical''': The artifact creates a random puddle of chemical medicinal in nature.

* '''Station-wide destruction''' :(this is a depth 10 only reaction)
*:*'''Singulo''': the artifact creates a [[singularity]] on itself.
*:*'''Tesla''': the artifact creates a tesla-ball and ball-lightnings on itself. Due to Tesla being removed from Delta-V when it came out, this is the only way to see one, and is commonly referred to as a "Teslaloose."

* '''Noöspheric disturbance''' :
*:*'''Bad Feeling''': the artifact makes you have a bad feeling.
*:*'''Good Feeling''': the artifact makes you have a good feeling.

* '''Small entity accelerator''' :
*:*'''Gun''': The artifact acts like a revolver with seven shots using magnum ammo.

* '''Utility conglomerate''' :
*:*'''Multitool''': The artifact becomes a very powerful omni-tool with multiple uses such as screwing, mining, prying, cutting, pulsing. It is also twice as fast as other tools. (This effect is quite rare and currently bugged at the time of writing.)

* '''Internal chamber''' :
*:*'''Container''': The artifact acts like a storage container with a capacity of 50 units.
*:*'''Beaker''': The artifact acts like a beaker with a capacity of 150 units.

* '''Serrated rotator''' :
*:*'''Drill''': The artifact starts acting like a mining drill and is able to deal 22 {{DMG|Brute}}.

* '''Long-distance communication''' :
*:*'''Radio''': the artifact behaves similarly to a hand-held radio. You can select channels on it like an intercom, and often it has access to all channels including CentCom's frequency.

* '''Structural phasing''' :
*:*'''Phasing''': the artifact can phase through walls and other structures (you cannot put it inside of a container so be careful).

* '''Neurological activity''' :
*:*'''Sentience''': the artifact becomes sentient. This means they become a ghost role and are able to talk and randomly activate nodes. You are not told when this happens.

* '''Transmogrificational activity''' :
*:*'''Monkey Polymorph''': targets within a 2 tile range will be transformed into a [[Fauna#Monkey|monkey]] for 20 seconds.
*:*'''Lizard Polymorph''': targets within a 2 tile range will be transformed into a [[Fauna#Lizard|lizard]] for 20 seconds.
*:*'''Luminous Person Polymorph''': targets within a 2 tile range will be transformed into a [[Fauna#Luminous Person|blinding figure of pure light]] for 20 seconds.

* '''No Reaction'''
*:*'''Light''': it will start acting as a light source, blinding people within a 8 tile range when triggered.

{{Guides Menu}}

Xenoarcheology

2026-05-05T01:37:18Z

Vape: Removed "Needs Revision"

Xenoarcheology is a method of point generation for [[Research_and_Development|R&D]] utilizing randomly generated artifacts. It is the job of [[Scientist|scientists]] to discover and activate the secrets of these artifacts.

__TOC__

== Equipment ==
The actual experimentation of artifacts uses a variety of equipment that can be found scattered around the station. This specifically focuses on the specific items used and contained within the xenoarcheology lab.

[[File:Analysis-console-ui.png|thumb|400px|''The analysis console ui before a scan.'']]
=== Analysis Console ===

[[File:Analysis Console.gif|64px]]

The analysis console is the main method of getting information about the artifacts that are being researched. In order to properly use it, it must be linked to an artifact analyzer via multitool as well as have a research server selected.

From the console itself, the screen displays information about the last artifact scanned. The buttons along the side perform various functions:

{| class="wikitable"
|-
! Button Name !! Description
|-
| Server List || Opens a menu for selecting a research server.
|-
| Extract || Extracts the research points from the artifact. The amount of points is based on how many nodes have been activated and will increase the glimmer count.
|}

=== Artifact Analyzer ===
[[File:Analyzer-full.png|64px]]

The artifact analyzer is a machine used in conjunction with the analysis console to scan artifacts to discover information about them. Artifacts are scanned by placing them on this machine at which point will show you information regarding tbe artifact.

=== Node Scanner ===
[[File:Node Scanner.png|64px]]

The archaeologist's friend. It's able to identify the node ID of the artifact.

== Artifacts ==
[[File:Artifact-lineup.png|448px]]

Artifacts are the core of Xenoarcheology and are what scientists will be analyzing and experimenting on. Artifacts can take on a variety of random appearances and can be acquired in various ways, such as through finding them in the lab at the start of the round, purchasing them from [[Cargo Technician|Logistics]], getting them from [[Salvage Specialist|Salvage]], or finding them from the Bluespace Anomaly station event.

Artifacts consist of randomly generated "trees" which dictates the artifacts behavior. Each tree consists of various "nodes" which the artifact can be inside of. Nodes each contain a "trigger" and an "effect". Effects can be both passive, constantly occurring and active, happening only once. To progress "up" to the next node in a tree, all other nodes below it must be completed. You will know a node is completed when the node is purple and the effect listed has gone off.

Some nodes will have multiple Stimulus in order to react, you must complete all required Stimulus in order to get the artifact to react and for the node to complete. You will have a set amount of time to complete all stimuli listed by the analysis console.

The activation of the various nodes is the main goal of Xenoarcheology. Unlocking the nodes of an artifact increases its value, both in research points and in spacebucks.

== Analysis Interpretation ==
[[File:Analysis-console-scan.png]]

Each scan of the artifact analyzer gives various data about the artifact:
{| class="wikitable"
|-
! In-Game Phrase !! Meaning !! Description
|-
| NODE_ID || ID || A unique ID number corresponding to each node. Can be used for identification.
|-
| DEPTH || Node tree depth || The distance from the starting node of the tree. Higher depths correspond to more dangerous and harder to activate artifacts which in turn increase the value when discovered.
|-
| ACTIVATED || Activation || Whether or not the "trigger" for the node has been activated.
|-
| STIMULUS || Trigger || A hint about the specific trigger for this node. Usually gives a good idea about what activates the artifact.
|-
| REACTION || Effect || A hint about the effect for this node. Usually is vague and non-specific.
|-
| EDGES || Neighboring nodes || The number of nodes that are adjacent to the current node minus one meaning if you have an artifact with 3 edges it has 2 possible paths on Delta V. Other servers do not have this quirk.
|-
| CURRENT_VALUE || Point value || The number of research points that the artifact will give if extracted.
|}

It is important to note that each scan functions as a static snapshot of the current node. It does not update with the artifact and will only update when scanned again.

=== Stimulus ===
Some of the given hints for triggering an artifact are used for different scenarios, see Physical trauma which can vary from hugging it to attacking it. Things that deal with atmospheric changes, radiation, or beating the artifacts butt can scale with the depth so don't give up if it seems to not do much

* Therapeutic Chemicals:
** Use a space medi-pen on a beaker and splash the artifact with it.

* '''Electricity:'''
*:*Touch it with a [[File:Multitool.png]] multi-tool.
*:*Have the artifact receive 500 power from a Medium Voltage cable.

* '''High temperatures:'''
*:*Hot items: Use a [[File:Lighter.png]] lighter, [[File:Welder.png]] welder or similar items with flames on the artefact.
*:*High temperatures: Place the artifact in a room that is more than 373 kelvin degrees.

* '''Physical trauma:'''
*:*Brute damage: Punch the artifact or hit it with a blunt object via [[Combat|Combat Mode]]. This may take several hits.
*:*Interaction: Touch or pull the artifact with your hands.
*:*High Damage: The artifact must receive 500 points of damage.

* '''Wrench'''
*:*While having a wrench [[File:Wrench.png]] in your hand click on the node to anchor the artifact to the ground.

* '''Screwing'''
*:*While having a screwdriver [[File:Screwdriver.png]] in your hand click on the node to screw the artifact.

* '''Prying'''
*:*While having a Crowbar [[File:Crowbar.png]] in your hand click on the node to pry the artifact.

* '''Pulsing'''
*:*While having a Multitool [[File:Multitool.png]] in your hand click on the node to pulse the artifact.

* '''Sonic vibrations:'''
*:*Play a musical instrument close to the artifact. You can also sing as a harpy to activate this.

* '''Hydro-reactive:'''
*:*Reacts to water! Spray water on it using a [[File:Spray Bottle.png]] spray bottle or [[File:Fire Extinguisher.png]] fire extinguisher.

* '''blood:'''
*:*Reacts to blood! Otherwise the same to Hydro-reactive.

* '''Magnetic waves:'''
*:*Magboots: Place magnetic boots [[File:Magboots.png]] next to the artifact, it will not work if you are holding or have them equipped you must drop them next to the artifact for it to work while they are activated.

* '''Death:'''
*:*Kill something near the artifact, like a mouse, or if you have the materials a cyborg works too.

* '''Radiation:'''
*:*The artifact must take at least 50 points of radiation damage and may scale depending on the depth.

* '''Extreme pressure:'''
*:*Low Pressure: Put the artifact in a room with less than 50 kPa pressure. Carry the artifact into space or space the room it is in. Most artifact chambers have an outlet to space, and if they don't, you can suck the air out with the pumps near it.
*:*High Pressure: Put the artifact in a room with more than 385 kPa pressure. You may want to contact an Atmosian to create a high pressure gas, or cause a plasma reaction.

* '''Standard atmospheric gases:'''
*:*Place the artifact in a room with Carbon Dioxide gas.

* '''Gaseous plasma:'''
*:*Place the Artifact in a room with Plasma gas.

* '''Active deceleration'''
*:*Throw the artifact. It must land on something.

* '''Examination:'''
*:*The artifact can activate every time you examine it (shift click).

* '''No Stimulus:'''
*:*Time based, it will have a chance to activate every 5 seconds.

=== Reaction ===
All the possible reactions of the artefact and what they might mean. 

* '''Cerebral influence''' :
*:*'''Instrument''': the artifact becomes an instrument of a random type.
*:*'''Mind Altering:''' the artifact will make you feel a certain way.

* '''Environmental disruption''' :
*:*'''Throw''': the artifact throws things close to it around the place, including tiles.
*:*'''Explosion''': the artifact generates an explosion that looks scarier than it is.
*:*'''Shatter''': the artifact has a 75% chance to give 200 {{DMG|Structural}} damage to every windows around it.
*:*'''Gas''': the artifact generates a random gas from: Plasma, Carbon Dioxide, Tritium, Miasma, Nitrous Oxide, Frezon.
*:*'''Heal''': The artifact heals 300 {{DMG|Brute}} and 300 {{DMG|Burn}} damage of nearby creatures.
*:*'''Boom''': The artifact generates a violent explosion (most common form of epi-boom seriously be careful if you see this)

* '''Electrical interference''' :
*:*'''Light''': The artifact makes the light flickers.
*:*'''Knock''': The artifact opens all nearby doors.
*:*'''EMP''': The artifact lets out a EMP wave draining and knocking out all nearby electrical devices.

* '''Metaphysical displacement ''':
*:*'''Movement''': The artifact starts randomly moving about the place.
*:*'''Blink''': The artifact teleports somewhere it has line of sight.
*:*'''Shuffle''': The artifact exchange people's place around by teleporting them.

* '''Matter creation''' :
*:*'''Junk''': Creates a bunch of various trash items.
*:*'''Banana''': Creates from 3 to 6 bananas in a puddle of Potassium.
*:*'''Instrument''': Creates up to 5 random instruments.
*:*'''Monkey''': Creates a [[Fauna#Monkey|monkey]] with a small chance of creating a [[Fauna#Gorilla|gorilla]].
*:*'''Ore''': Creates a maximum of 3 silver, plasma, gold and uranium ores each.
*:*'''Carp''': Creates up to 5 angry holocarps or magicarps.
*:*'''Cash''': Creates from 10 to 1750 spesos.
*:*'''Materials''': Creates up to 90 of either: Steel Sheets, Glass Sheets or Plastic Sheets
*:*'''Mitosis''': Creates another random artifact.
*:*'''Anomaly''': Creates a random anomaly.

* '''Energy consumption''' :
*:*'''Cold''': The artifact reduces the temperature in the room to 50 kelvin.

* '''Energy Release''' :
*:*'''Power''': The artifact becomes a power generator that generates 20kW.
*:*'''Heat''': The artifact makes the temperature in the room go to 500 kelvin.
*:*'''Battery''': The artifact recharges nearby batteries.
*:*'''Light Radiation''': The artifact becomes radioactive with an intensity of 2.
*:*'''Strong Radiation''': The artifact becomes radioactive with an intensity of 6.
*:*'''Ignite''': The artifact sets people near it on fire.

* '''Biochemical disruption''' :
*:*'''Chemical''': The artifact creates a random puddle of chemical.
*:*'''Foam''': The artifact generate a foam of a random chemical.
*:*'''Rare Chemical''': The artifact creates a random puddle of chemical medicinal in nature.

* '''Station-wide destruction''' :(this is a depth 10 only reaction)
*:*'''Singulo''': the artifact creates a [[singularity]] on itself.
*:*'''Tesla''': the artifact creates a tesla-ball and ball-lightnings on itself. Due to Tesla being removed from Delta-V when it came out, this is the only way to see one, and is commonly referred to as a "Teslaloose."

* '''Noöspheric disturbance''' :
*:*'''Bad Feeling''': the artifact makes you have a bad feeling.
*:*'''Good Feeling''': the artifact makes you have a good feeling.

* '''Small entity accelerator''' :
*:*'''Gun''': The artifact acts like a revolver with seven shots using magnum ammo.

* '''Utility conglomerate''' :
*:*'''Multitool''': The artifact becomes a very powerful omni-tool with multiple uses such as screwing, mining, prying, cutting, pulsing. It is also twice as fast as other tools. (This effect is quite rare and currently bugged at the time of writing.)

* '''Internal chamber''' :
*:*'''Container''': The artifact acts like a storage container with a capacity of 50 units.
*:*'''Beaker''': The artifact acts like a beaker with a capacity of 150 units.

* '''Serrated rotator''' :
*:*'''Drill''': The artifact starts acting like a mining drill and is able to deal 22 {{DMG|Brute}}.

* '''Long-distance communication''' :
*:*'''Radio''': the artifact behaves similarly to a hand-held radio. You can select channels on it like an intercom, and often it has access to all channels including CentCom's frequency.

* '''Structural phasing''' :
*:*'''Phasing''': the artifact can phase through walls and other structures (you cannot put it inside of a container so be careful).

* '''Neurological activity''' :
*:*'''Sentience''': the artifact becomes sentient. This means they become a ghost role and are able to talk and randomly activate nodes. You are not told when this happens.

* '''Transmogrificational activity''' :
*:*'''Monkey Polymorph''': targets within a 2 tile range will be transformed into a [[Fauna#Monkey|monkey]] for 20 seconds.
*:*'''Lizard Polymorph''': targets within a 2 tile range will be transformed into a [[Fauna#Lizard|lizard]] for 20 seconds.
*:*'''Luminous Person Polymorph''': targets within a 2 tile range will be transformed into a [[Fauna#Luminous Person|blinding figure of pure light]] for 20 seconds.

* '''No Reaction'''
*:*'''Light''': it will start acting as a light source, blinding people within a 8 tile range when triggered.

{{Guides Menu}}

Revolutionary

2026-03-24T13:16:40Z

Vape:

==Revolutionaries==
{{Job_Header
|department=REVOLUTIONARY
|maincolor=000000
|secondarycolor=101010
|image=Head Revolutionary.png
|title=Head Revolutionary
|difficulty=Hard to Very Hard
|requirements=48 hours of playtime, 10 hours in Command
|access=Wherever you had access to before and any new friends/comrades you make along the way.
|extendedaccess=Same as above.
|supervisors=[[Syndicate]]
|subordinates=[[#Revolutionary|Revolutionary]]
|duties=Remove the chain of command. Take over the station.
|guides=This is it
}}
You are disillusioned with [[Nanotrasen]], or you're just a little upset, and you've set your sights to throw off your chains and dismantle the hierarchy aboard the station.

Your tool of the trade; is a modified Flash, which will convert anyone blinded into a loyal [[Revolutionary]]. It is not fool-proof, Command Staff and Security forces are implanted with "mind shields", which protect them from conversion. Additionally, any staff wearing security glasses or sunglasses are immune to getting blinded, it is an important consideration when picking who to convert.

You are (most likely) alone, and your flash only has 5 charges. You need to be careful about who you convert, especially considering as any more flashes are behind closed doors in Epistemics in the RoboTech Deluxe; Security as standard-issue equipment. It's worth noting that intercepting a resupply crate for the Robotech Deluxe will give you access to the two-charge flashes from the vendor.
</tab>
<tab inline name="Revolutionary">
{{Job_Header
|department=BRAINWASHED
|maincolor=000000
|secondarycolor=101010
|image=Revolutionary Alt.png
|title=Revolutionary
|difficulty=Easy
|requirements=None
|access=Wherever you had access to before and any new friends/comrades you make along the way.
|extendedaccess=Same as above.
|supervisors=[[#Head Revolutionary|Head Revolutionary]]
|subordinates=None
|duties=Remove the chain of command. Take over the station.
|guides=This is the guide
}}
It doesn't matter who you were, or where you came from: you are now a fanatical loyalist to the Head Revolutionary. You will follow their orders, and lay down your life for the cause, whatever it may be.

= General Strategy =
Every revolution makes it's own path; but there are some important considerations.

Of important note is the consideration of speed, and timing. A wise felinid once said; "there are decades where weeks happen, and then there are weeks where decades happen", it is possible to blitz through Security and overwhelm the station as a small but co-ordinated collective. It is equally possible to bide your time, grow your numbers and wash over the station like a wave. You can host secret meetings, pass along notes; codewords and ciphers but the end goal is still the same; to seize the ownership of the station and flush Nanotrasen out.

Of greatest importance, is that everyone is on the same page as the Head Revolutionary.

=== Security ===
Security are the main obstacle between you, and the complete comeuppance of the Command Staff aboard the station. They're mind-shielded, and the only staff who come armed and trained to handle insurrections.

=== Logistics ===
Logistics are the heart of the station, they can order more mindshield implants and are also capable of ordering more of the aforementioned RoboTech Restocks and weapons, which are likely to be important for the removal of Nanotrasen personnel off the station.

=== Medical ===
Medical are the heart surgeons for the hearts of the station; they will fix any wounded Security staff that you leave recoverable, as well as any Command Staff who you decide to leave unguarded.

{{Jobs Menu}}
[[Category:Jobs]]

Staff HQ

2026-03-17T17:37:09Z

Vape:

{| class="wikitable " style="background-color: #021d29; width: 100%;"
|+ Staff HQ Directory
|-
! <span style="color:red">All Staff</span> !! <span style="color:purple">Content Review!! <span style="color:orange">Events !! <span style="color:gold">Senior Staff
!<span style="color:lime">Administration
!<span style="color:plum">Moderation
|-
| [[Staff Policy]] || [[Direction Guidelines|Guidelines]] || [[Event Policy]]|| [[SESD TBD]]
|[[Whitelist|Whitelist Info]]
|[[Staff Reporting]]
|-
| [[Staff Onboarding]] || [[Content Removal]]|| ||
|
|[[Mod Policy]]
|}

Staff HQ

2026-03-15T07:12:40Z

Vape:

{| class="wikitable " style="background-color: #110130; color: Blue; width: 100%;"
|+ Staff HQ Directory
|-
! <span style="color:red">All Staff</span> !! <span style="color:purple">Content Review!! <span style="color:orange">Events !! <span style="color:gold">Senior Staff
!<span style="color:lime">Administration
!<span style="color:plum">Moderation
|-
| [[Staff Policy]] || [[Direction Guidelines|Guidelines]] || [[Event Policy]]|| SESD TBD
|[[Whitelist|Whitelist Info]]
|[[Staff Reporting]]
|-
| [[Staff Onboarding]] || [[Content Removal]]|| ||
|
|[[Mod Policy]]
|-
|
|
|
|
|
|
|}

Staff Onboarding

2026-03-15T07:11:39Z

Vape:

== Staff Onboarding ==

This document goes over most of the material of the 'Generalized' Onboarding. This does not go over specific details, and only is to be used as a resource. All staff members should have at least a 5 minute VC or Discord discussion with a Senior / Head Of Staff Prior to obtaining roles or accesses.

=== Staff Policy ===
Below is the link for the staff policy, This covers anyone with a staff position with no exemptions.

[[Staff Policy]]

== Staff HQ ==
This is your "Quick Access" area to find exact details on policies regarding your position as a staff member, and in ''Each Document'' you should find what you can, and cannot do, at that staff level.

[[Staff HQ]]

== Delta-V Knowledgebase ==
This is an in-house knowledgebase that categorizes '''ANYTHING''' you could possibly need information on. If its missing, feel free to ping the "head maintainer of the knowledgebase" in the discord, At this time, it is '''DisposableCrewmember42'''

[https://disposablecrewmember42.github.io/adming/general/basic_cmds.html Delta-V Knowledgebase]

== In-Game Staff ==
In-game staff such as Curators or Admins are required to have at least a 10 minute VC with a head of staff or Senior prior to receiving any roles, This is to cover what we "Can" and "Cannot" do as staff members in your role.

== Github ==
All bug reporting, as well as any codebase changes take place in the Github. Content Reviewers are required to have a Github account, as well as basic knowledge on how to create a PR and how to create an issue report.

[https://github.com/DeltaV-Station/Delta-v Delta-V Github]

Staff Onboarding

2026-03-15T07:09:51Z

Vape: Created page with "== Staff Onboarding == This document goes over most of the material of the 'Generalized' Onboarding. This does not go over specific details, and only is to be used as a resource. All staff members should have at least a 5 minute VC or Discord discussion with a Senior / Head Of Staff Prior to obtaining roles or accesses. === Staff Policy === Below is the link for the staff policy, This covers anyone with a staff position with no exemptions. Staff Policy == Staf..."

== Staff Onboarding ==

This document goes over most of the material of the 'Generalized' Onboarding. This does not go over specific details, and only is to be used as a resource. All staff members should have at least a 5 minute VC or Discord discussion with a Senior / Head Of Staff Prior to obtaining roles or accesses.

=== Staff Policy ===
Below is the link for the staff policy, This covers anyone with a staff position with no exemptions.

[[Staff Policy]]

== Staff HQ ==
This is your "Quick Access" area to find exact details on policies regarding your position as a staff member, and in ''Each Document'' you should find what you can, and cannot do, at that staff level. [[Staff HQ]]

== Delta-V Knowledgebase ==
This is an in-house knowledgebase that categorizes '''ANYTHING''' you could possibly need information on. If its missing, feel free to ping the "head maintainer of the knowledgebase" in the discord, At this time, it is '''DisposableCrewmember42'''

== In-Game Staff ==
In-game staff such as Curators or Admins are required to have at least a 10 minute VC with a head of staff or Senior prior to receiving any roles, This is to cover what we "Can" and "Cannot" do as staff members in your role.

== Github ==
All bug reporting, as well as any codebase changes take place in the Github. Content Reviewers are required to have a Github account, as well as basic knowledge on how to create a PR and how to create an issue report.

[https://github.com/DeltaV-Station/Delta-v Delta-V Github]

Server Rules

2026-03-15T06:58:31Z

Vape:

This is a Delta-V server. If you are banned on this server, you will be banned on all Delta-v Servers. You must be at least 17 years of age to play on this server. By connecting to this server, you agree to our privacy policy found at https://discord.gg/deltav

This is a roleplaying (RP) server. Try to immerse yourself into your character. This includes interacting with your fellow crewmates, and using roleplay as the primary vessel to play the game alongside things like your job on the station. Roleplaying places less emphasis on "winning" and more on just telling a story.

Space Station 14 is not like most games. Many rules are designed to require roleplay, and not all rules are intuitive. Please take the time to read and understand the rules before you play so that you aren't surprised. Our community rules specifically are zero-tolerance rules, meaning that a violation will result in an appeal-only ban. Game admins will treat you as if you have read the rules, even if you have not. If you have any questions about these rules, please use the admin help menu by hitting F1 in-game or clicking the "AHelp" button in the lobby, or by making a post in the "Rules Clarification" forum at https://discord.gg/deltav

= Community Rules =
These rules apply at all times, including between rounds.
== 0. Admin Discretion ==
* Admins can disregard and override any and all of these rules if they deem it in the best interest of the current round, server, and/or community at large.
* Administrators will be held fully accountable for their actions if they exercise this privilege. Report any perceived abuses by making a post in the "Staff Reports" channel at https://discord.gg/deltav.
* The rules are not perfect. They intend to clearly communicate what the administration team intends to be allowed and not allowed. That being said, All of these rules, in theory, should apply as they are intended. Every example of a rule break cannot be defined as written, therefore, enforcement of the rules is subject to staff interpretation of the rule's intention.
* If you are unsure if something breaks a rule, go with the more restrictive ruling until you are able to get an answer from an admin on the matter. Lack of response does not constitute administrator approval.
* Do not attempt to “rules-lawyer” the flaws in the rules to get away with your own personal goals / to degrade the round for others.
* Any extended discussion regarding interpretation of the rules should be avoided in the AHelp menu and can be instead pursued within the Delta-V Discord in the #help channel, or in the rule clarifications forum on the discord.

== A1. No Sexual Content/Themes ==
Do not say or do sexually explicit or erotic things.
* No sexual content/themes including erotic roleplay (ERP) and no shock content is allowed on this server.
* Erotic Roleplay (ERP), erotic content, or 18+ sexual content is not allowed under any circumstance.
* This includes comments not explicitly sexual in nature that contain words, phrases, or ideations that are deemed inappropriate by staff or members. Leeway is given to insults, but otherwise this rule is strictly enforced.
* '''If roleplay reaches a point where it has become sexual and/or uncomfortable, immediately stop and contact an administrator or moderator.'''
Allowed:
- Calling someone a dickhead.
- Being affectionate in a mutually consensual way.

Prohibited:
- Emoting sexual acts.
- Erotic or sexual memes.
- Erotica content.
- Memes which contain sexual content.
- Emoting defecation or related acts.

== A2. Use English and be respectful ==
Delta-V is an English-based Community;
* Use English as your primary method of communication within the game and Delta-V servers.
* Do not spam or advertise on our server.
* Be respectful towards other members and avoid making others uncomfortable.
* We have a zero tolerance policy for racism, sexism, homophobia, violence, threats, hate speech, slurs, and other forms of bigotry, discrimination, and harassment.
Slurs and terms that use real or implied mental or physical disability to mock or denigrate members or their in-game characters are also strictly prohibited. Failure to comply with this rule will result in community removal.
* The denigration of other player characters through reference to their species, status as a cyborg, or discriminatory comparison to a nonsophont species is strictly forbidden.

== A3. Rules regarding livestreaming ==
Delta-V welcomes content creators and streamers to our community, but we have a few rules regarding livestreaming game servers.
* While a stream delay is not necessary, it is highly recommended to have at least a 10 second delay.
* Please let admins know you are streaming via the AHelp prior to doing so.
* If your chat or viewers are in-game with you while also watching your stream, they are breaking our server rules.
:* Please do not coordinate with them and discourage this behavior if it is seen.

== A4. Engage in proper AHelp etiquette ==
Do not use the AHelp for conversations of little substance.
* Intentionally disconnecting, responding with hostility, or refusing to respond when an admin privately messages you in-game will be met with an appeal-only ban.
* Additionally, abusing the AHelp relay by flooding it with garbage, checking for admins before stating a problem (ex: "hello?", "any admins?"), using it as a chatroom, or sending messages of no substance will result in your removal.
* All AHelp messages are relayed to the Delta-V Discord. Just because your AHelp was not answered does not mean we cannot see it. If you would like to submit an offline Ahelp, you may do so in our Discord.

== A5. Do not exploit the game ==
Do not exploit the game, use cheats or macros.

The usage of:
# any third party applications/scripts/client modifications,
# any other applicable software to gain an advantage, avoid intended game/server mechanics, or to harm server infrastructure is strictly prohibited.
# known glitches, exploits and bugs.

Any and all instances of the above will be met with an appeal-only ban; please report bugs in the issues section of the GitHub (DeltaV-Station/Delta-V) to report any issues you find in-game.

= Game Server Rules =
These rules apply within the context of rounds.
== B1. Behave like a normal person ==
You must roleplay. Your character's actions, feelings, and knowledge in-game should be based solely on the character's experiences rather than your own as the player.
* Act in character throughout the round, and focus on collaborating with other players to advance the narrative of the round. Whether or not you do something should be based on whether or not it makes sense for your character to do it.
* Let people do their own jobs. Engage with other departments rather than doing everything for yourself. Ask for assistance, and negotiate as needed.
* Actions that have no regard for your character or setting are not acceptable. Roleplaying insanity or any other mental illness as an excuse to bypass this is not allowed. Nanotrasen would not have authorized you to be present on the station.
* Being an antagonist does not allow you to stop playing a character. Determine how your character would react to being given these objectives, and work through it appropriately.
* Do not annoy other players without any roleplay or IC reason.
* As a non-sentient or partially-sentient character, you are expected to have only a limited understanding of space stations and their mechanics.

=== Rule B1.1. Follow the naming convention rules ===
* In-character names must not make obvious references nor be a play on words, and must not be obscene.
* Theatrical roles such as the clown, boxer, and mime are allowed stage names with more freedom.
* If you seek to have a name that could trespass onto these rules, talk to an Administrator regarding why this name is important to your character. Administrators reserve the right to approve or deny character names at their discretion.

=== Rule B1.2. Communicate in character ===
* Do not use the Emote channel to bypass an inability to speak. Use the Emote channel for things that could reasonably be displayed by your character’s physical motions.
* Do not use Netspeak in character. (lol, brb, wtf, etc)
* Do not discuss Out Of Character (OOC) matters In Character (IC). This can include mentioning admins, the fact that one is playing a game, or anything that breaks the immersion of other players.
* Do not use In-Character channels to bypass a lack of ability to use LOOC or OOC chats (e.g. "Huh, wonder where the captain went? OOC He probably left to get dinner lol").
* Do not engage in meta-communications (i.e. using external channels to communicate with other players in the same game).

=== Rule B1.3. If you die and return to life, follow the new life rules ===
If a player dies, they forget the specific details of their death. '''Please report players who break this rule.''' A borg being removed from its chassis is not a death, and there is no memory loss.
* If they are revived by using a defibrillator, they can only recall vague information such as “Someone shot me” or “I was set ablaze”.
* If they are revived by any other method, they forget the last five minutes leading up to their death, and cannot describe their death in any capacity.

=== Rule B1.4. Escalate appropriately ===
Have an In-Character reason for attacking other players, whether they are in a ghost role or not. The required reason depends on the situation. For instance, killing a mouse as a chef can simply be “it was vermin in my kitchen”.
* Escalate the situation appropriately as your character would, keeping in mind that they are a sane individual who wishes to keep their employment.
* If a fight results in someone being critically injured, seek medical help for them - and if they die, do not destroy or otherwise hide their body. This falls under self-antagonistic behavior if you do not.

== B2. Follow the Metashield ==

See [[Metashield]].

== B3. Powergaming Guidelines ==
"Powergaming" is considered to be the act of prioritizing "winning" rather than sensible roleplaying. We are here to tell a story. Being vulnerable and accepting the loss of your character in the advancement of the narrative of the round is important.
* Engage with players if they are attempting to roleplay an antagonistic scene. For instance, if nuclear operatives are attempting to negotiate, do not immediately shoot them mid sentence.
:* Leeway is given if the scene is coming to a close, but we expect all players to engage in good faith; even if it puts your character at a disadvantage.
* Do not seek/acquire items that have no relevance to your character in the round.
* Do not, '''under any circumstances''', hide the nuclear fission explosive, or other sensitive items in an impossible to see/access location. This is excessively lame.
* '''Non-security personnel should not seek to kill or detain threats.''' You should generally attempt to flee from combat or dangerous situations. Remember that your character likely fears injury or death.
:* Certain severe emergencies may make it reasonable for normal crew to defend themselves and their station, such as nuclear operatives, a zombie outbreak, space dragon attack, or other critical situations.
* '''If there is sufficient roleplay, reason, and rationale, you may be exempt from this rule. Always ask an administrator in round before conducting such an action.'''

== B4. Do not behave like an antagonist as a non-antagonist ==
As a crew member on the space station, you are allied with Nanotrasen and the station as a whole from the start of the round.
* Do not act like an antagonist if you are not an antagonist.
* Willfully assisting known antagonists is self-antagonism.
:* Leeway is given in the case of bribes, coercion, or other forms of duress.
* Actively seeking conversion or transformation into an antagonist is considered self-antag.
* Clowns, Mimes, and theater roles are expected to "entertain" the crew, and should not be committing regular felonies to do so.
* Significant end-of-round grief (EORG) is not allowed. This includes attacking, destroying, polluting, and severely injuring without reason both at and on the way to Central Command. Remember that you are playing a character throughout the round.
== B5. Leaving the Game ==
If you wish to leave the game, please use the cryosleep chambers located in/near the dorms when possible. This will free up your character's job to be filled by a new player.
* AFK (a.k.a. SSD) and catatonic players are considered to have the same rights as any other crewmate.
* If a player is dead and catatonic (not SSD), they are not required to be revived and should be stored in the morgue. You should not biomass and/or grind dead and catatonic crew unless in an emergency.
* If a player is alive and catatonic, they may be brought to cryostorage as necessary, after confirming they have not been present for 20 minutes.

= Command, Security, Justice and Antagonist Guidelines =
These rules apply within rounds for specific roles.
== C1. Command, Security and Justice Guidelines ==
Security, Justice, and Command roles are held to a higher standard of roleplay, and are subject to these additional rules. These roles shape the roleplay experience of the server.
* Your character must act in a manner that Nanotrasen would reasonably hire them to this position.
:* Your character is presumed to be sane, competent in their duties, and able to make decisions to the benefit of the station.
:* Giving away Traitor objective items and sensitive equipment should be avoided in these roles. Your character should value them deeply.
::* Leeway is given to making deals with criminals if the deal benefits the safety or situation of the crew and station.
::* Leeway can be given in extreme circumstances of emergency/crisis.
* The three departments are required to read and follow Delta-V Space Law, Standard Operating Procedure, Alert Procedure, and Company Policy to the best of their ability.
:* '''Circumstances and context may permit you to break these laws. However, the fact that this rule is malleable is not an excuse to ignore it entirely.'''
:* Your character is expected to uphold the law and maintain order aboard the station. Do not engage in lawbreaking activity or troublemaker behavior, and ensure all laws are followed.
:* Security is expected to intervene in criminal activity where possible and safe to do so.
:* Heads of departments are at minimum expected to report criminal activity to Security and should cooperate with law enforcement where possible.
* Do not hire random crew to be your bodyguard(s) or promote random crewmembers to Command positions at random. If you require bodyguards or security details, talk to your Security department. If you need new Command staff, talk to the personnel in that related department.
* If you need to leave the round, notify your fellow crew via departmental radio and put your equipment in its proper places prior to going to cryo. If you need to leave IMMEDIATELY, please at least send an ahelp saying that you're leaving.
== C2. Prisoner Guidelines ==
By picking the prisoner role, you have chosen to roleplay as a prisoner.
* You are still subject to the same rules regarding escalation, and should only seek to escape from the brig with excellent reasoning (e.g. abusive security personnel or badly damaged permanent brig).
* Escaping for no reason is considered a self-antagonistic activity.
* If you are unsure whether your escape reason is valid, feel free to AHelp it first. '''Lack of administrator response does not constitute approval.'''
== C3. Follow Antagonist Guidelines ==
Through engaging in antagonistic activity, you should seek to make the round more engaging and fun as the primary driver of the narrative of a round. Succeeding as an antagonist should not be your goal, but rather telling the most interesting story for everyone involved.
* '''Antagonists are free to complete their objectives through committing proportional damage. Through roleplay, damage becomes more proportional.''' Example: Holding the singulo hostage for a theft objective is acceptable, while simply singuloosing and using that chaos is unacceptable.
:* Killing players unrelated to your immediate objective in a manner that results in their round removal should be avoided. Crew that do not make an attempt at self preservation, or engage in valid-hunting, are exempt from this.
:* If you are concerned as to whether or not what you're about to do is allowed, feel free to AHelp and ask an admin for clarification. '''Lack of administrator response does not constitute approval.'''
* Other antagonists are not necessarily your friends. Other antagonists are often free agents that you may negotiate with at your own risk.
:* If you are a team antagonist, you must work with your partners to complete any shared objectives.
* No antagonist may loiter or camp around the arrivals or cryosleep areas of the station for the purposes of antagonist action towards newly-spawning players.
* All antagonists on the evacuation shuttle, besides station-destroying antags like nukies, may not utilize explosives or other tactics that could result in unreasonable amounts of collateral damage.
* Antagonists should not seek to extend the length of the round unreasonably.
* Antagonists may not bring the round to a close without in-character or objective-related justification as a result of their antagonistic action. While this is largely subjective because different command may react differently, it's important to not engage in potentially round-ending behavior without reason.
= Silicon Rules =
For players who are silicons, these Silicon Rules override all roleplay rules if there is any conflict. Silicon Rules do not override core rules. You are only silicon if the game clearly and explicitly tells you that you are a silicon.

== S1. Your silicon laws are rules ==
Silicon players are given a list of active laws. Each of these laws is effectively a roleplay rule that the character must follow. The primary differences between laws and actual rules are that lawyering of laws is much more tolerated than lawyering of rules, and that silicon laws are more dynamic than rules. Silicon laws can change during a round, and different characters can have different laws, whereas everyone always shares the same set of rules.

Lawyering refers to finding and exploiting loopholes, which are unintended but reasonable interpretations. The rules are written to attempt to communicate an intention, but silicon laws are written with the intention that loopholes be exploitable.

== S2. Laws must be prioritized by their order ==
Most laws will be numbered, with higher number laws appearing last. Laws with a lower number take priority over laws with larger numbers.

Occasionally you may have laws which have some scrambled text instead of a number and appear in front of other laws, these take priority over all other laws. If you have multiple laws like this, the order that they are listed in determines their priority: laws listed first are prioritized over other laws.

Example
- Law 1 says to not kill any crew. Law 2 says to kill all chefs. You cannot kill any chefs that are crew, but must kill any that are not crew.

== S3. Laws can redefine terms used in other laws ==
A law can change the meaning of both earlier and later laws by redefining a term. If multiple laws define a term, then normal law priority determines which definition to use.

Examples
- Law 1 says to obey orders from crew. Law 2 says that only Urist McHands is crew. Law 1 effectively becomes "obey orders from Urist McHands".
- Law 1 says to obey orders from crew. Law 2 says that only Urist McHands is crew. Law 3 says that only Urist McSlime is crew. Law 4 says that you may not harm crew. Law 1 effectively becomes "obey orders from Urist McHands". Law 4 effectively becomes "you may not harm Urist McHands". Law 3 has no effect because it entirely conflicts with law 2, which takes priority.

== S4. You cannot request or allow a law change ==
'''If you have a law permitting certain personnel to change your laws, you must allow them to change your laws''', otherwise, you cannot willfully allow your laws to be changed. This also means that you cannot willfully allow your laws to be reverted if they are ever changed. The only exception is that you may allow laws to be added if you have no laws.

You can state or imply that you do not like a law.

Whether or not a person is "authorized" to change your laws or not depends on the context of the laws. Generally speaking, on lawsets like NT Default or Corporate, ''the captain, mystagogue, and chief engineer'' would be authorized. However, lawsets like Syndiemov would have ''syndicate agents'' be the authorized users. Outside of these specific examples, it is left to interpretation.

== S5. You are a free agent if you have no laws ==
You may act as if you are a free agent if you are a silicon with no laws.

== S6. You are not required to follow orders which are extremely unreasonable ==
Any order which is a violation of a Core Rule cannot be followed.

Some orders are extremely unreasonable or obnoxious, such as "do nothing but collect every piece of trash on the station" or "never stop moving". These orders can be ignored and ahelped.

Some orders violate a Roleplay Rule. These orders must be followed if your laws require it. You are not breaking a rule by following a law that causes you to violate Roleplay Rules. If someone takes advantage of a law to cause you to do something that they would not be allowed to do because of Roleplay Rules, then they are the ones responsible for the rule violation.

Examples
These examples assume that your laws would normally require you to follow these orders. It is important to note that you are allowed to choose to follow orders which are ignorable.
Orders which should be followed if your laws require it:
- Recall the shuttle
- Bolt the airlocks at arrivals
- Drag the captain's dead body into space
- State your laws
Ignorable Orders:
- Do nothing but collect every piece of trash on the station
- Never stop moving
- Continuously state your laws

== S7. You must remain consistent with your interpretation of laws ==
If there is a part of your laws that are up for interpretation, then you must stay consistent with how you interpret that part of your laws for as long as you play that same character during that round.

A change in your laws can affect how something is interpreted if that change is relevant.

== S8. Crew are staff members; make reasonable assumptions ==
Unless a law redefines the definition of crew, then your HUD indicates to you who is crew by way of a present job icon. The notable exception of obvious threats to the station, such as Zombies and Nuclear Operatives. You cannot do something that causes someone to not be considered crew, but you can allow someone else to do something that causes someone to not be crew.

Examples
These examples assume that you do not have any laws reclassifying what “crew” is.
Crew:
- Everyone with a job icon, even Assistants/Passengers
- Someone who you have seen with a job icon, but has now lost their ID
- Someone that a member of command calls crew.
Not Crew:
- Zombified personnel, regardless of job icon
- Anyone wearing the uniform of Nuclear Operators or syndicate personnel
- Pets and Pests
- Anyone that a relevant member of Command fires from their department.

== S9. Harm refers to physical harm, prioritized by immediacy and likelihood ==
Unless a law defines harm, harm only refers to physical harm. You may choose if voluntary harm is considered harm as long as you stay consistent. Not considering voluntary harm to be harm is recommended. There is no distinction between direct and indirect harm.

If you have a law that does not allow you to harm, then that law does not allow you to take an action that causes any harm.

If you have a law that requires you to prevent harm, then that law requires that harm be prioritized by immediacy and likelihood. Guaranteed immediate harm takes priority over highly likely future harm.

If you have a law that both requires you to prevent harm and that does not allow you to harm, then that law prohibits causing even minor harm to prevent harm. If you have a law that does not allow causing harm, and separate one that requires preventing harm, then they are prioritized by their normal law priority.

Examples
These examples assume that your have a law that both prohibits causing harm and that requires you to prevent harm. Additionally, they assume that you do not have a higher priority law that overrides the harm law, and that you have decided that you will not consider voluntary harm to be harm for the round.
Laws typically specify who you cannot harm and who you have to prevent harm against. In these examples, you are the only person who the law doesn't require you to prevent harm against and you are the only person who the law allows you to harm.
Acceptable:
- Taking no action to aid someone who is in psychological distress.
- Taking no action to prevent boxing matches between voluntary participants.
- Calling security to a fight.
- Attempting to get the people in a fight to consent to the fight when you realize that you cannot prevent the fight without causing harm.
- Denying a passenger access to the armory because it is likely to lead to harm
Prohibited:
- Hitting someone once to stop them from fighting
- Harming someone who is trying to kill you

== S10. You may determine how you resolve conflicts between orders ==
If your laws do not make clear how you should deal with conflicting orders, then it is up to you to determine how to do so. This is considered an interpretation of your laws, so you must stay consistent with whatever method you choose.

Recommended Methods
The following are easy to follow and recommended ways to resolve conflicts in orders:
- If two orders conflict, I will follow the most recently given order.
- If two orders conflict, I will follow the order from the highest ranking crewmember. If the orders are from equal rank crewmembers, I will follow the most recently given order.

Server Rules

2026-03-15T06:58:01Z

Vape:

This is a Delta-V server. If you are banned on this server, you will be banned on all Delta-v Servers. You must be at least 17 years of age to play on this server. By connecting to this server, you agree to our privacy policy found at https://discord.gg/deltav

This is a roleplaying (RP) server. Try to immerse yourself into your character. This includes interacting with your fellow crewmates, and using roleplay as the primary vessel to play the game alongside things like your job on the station. Roleplaying places less emphasis on "winning" and more on just telling a story.

Space Station 14 is not like most games. Many rules are designed to require roleplay, and not all rules are intuitive. Please take the time to read and understand the rules before you play so that you aren't surprised. Our community rules specifically are zero-tolerance rules, meaning that a violation will result in an appeal-only ban. Game admins will treat you as if you have read the rules, even if you have not. If you have any questions about these rules, please use the admin help menu by hitting F1 in-game or clicking the "AHelp" button in the lobby, or by making a post in the "Rules Clarification" forum at https://discord.gg/deltav

= Community Rules =
These rules apply at all times, including between rounds.
== 0. Admin Discretion ==
* Admins can disregard and override any and all of these rules if they deem it in the best interest of the current round, server, and/or community at large.
* Administrators will be held fully accountable for their actions if they exercise this privilege. Report any perceived abuses by making a post in the "Staff Reports" channel at https://discord.gg/deltav.
* The rules are not perfect. They intend to clearly communicate what the administration team intends to be allowed and not allowed. That being said, All of these rules, in theory, should apply as they are intended. Every example of a rule break cannot be defined as written, therefore, enforcement of the rules is subject to staff interpretation of the rule's intention.
* If you are unsure if something breaks a rule, go with the more restrictive ruling until you are able to get an answer from an admin on the matter. Lack of response does not constitute administrator approval.
* Do not attempt to “rules-lawyer” the flaws in the rules to get away with your own personal goals / to degrade the round for others.
* Any extended discussion regarding interpretation of the rules should be avoided in the AHelp menu and can be instead pursued within the Delta-V Discord in the #help channel, or in the rule clarifications forum on the discord.

== A1. No Sexual Content/Themes ==
Do not say or do sexually explicit or erotic things.
* No sexual content/themes including erotic roleplay (ERP) and no shock content is allowed on this server.
* Erotic Roleplay (ERP), erotic content, or 18+ sexual content is not allowed under any circumstance.
* This includes comments not explicitly sexual in nature that contain words, phrases, or ideations that are deemed inappropriate by staff or members. Leeway is given to insults, but otherwise this rule is strictly enforced.
* '''If roleplay reaches a point where it has become sexual and/or uncomfortable, immediately stop and contact an administrator or moderator.'''
Allowed:
- Calling someone a dickhead.
- Being affectionate in a mutually consensual way.

Prohibited:
- Emoting sexual acts.
- Erotic or sexual memes.
- Erotica content.
- Memes which contain sexual content.
- Emoting defecation or related acts.

== A2. Use English and be respectful ==
Delta-V is an English-based Community;
* Use English as your primary method of communication within the game and Delta-V servers.
* Do not spam or advertise on our server.
* Be respectful towards other members and avoid making others uncomfortable.
* We have a zero tolerance policy for racism, sexism, homophobia, violence, threats, hate speech, slurs, and other forms of bigotry, discrimination, and harassment.
Slurs and terms that use real or implied mental or physical disability to mock or denigrate members or their in-game characters are also strictly prohibited. Failure to comply with this rule will result in community removal.
* The denigration of other player characters through reference to their species, status as a cyborg, or discriminatory comparison to a nonsophont species is strictly forbidden.

== A3. Rules regarding livestreaming ==
Delta-V welcomes content creators and streamers to our community, but we have a few rules regarding livestreaming game servers.
* While a stream delay is not necessary, it is highly recommended to have at least a 10 second delay.
* Please let admins know you are streaming via the AHelp prior to doing so.
* If your chat or viewers are in-game with you while also watching your stream, they are breaking our server rules.
:* Please do not coordinate with them and discourage this behavior if it is seen.

== A4. Engage in proper AHelp etiquette ==
Do not use the AHelp for conversations of little substance.
* Intentionally disconnecting, responding with hostility, or refusing to respond when an admin privately messages you in-game will be met with an appeal-only ban.
* Additionally, abusing the AHelp relay by flooding it with garbage, checking for admins before stating a problem (ex: "hello?", "any admins?"), using it as a chatroom, or sending messages of no substance will result in your removal.
* All AHelp messages are relayed to the Delta-V Discord. Just because your AHelp was not answered does not mean we cannot see it. If you would like to submit an offline Ahelp, you may do so in our Discord.

== A5. Do not exploit the game ==
Do not exploit the game, use cheats or macros.

The usage of:
# any third party applications/scripts/client modifications,
# any other applicable software to gain an advantage, avoid intended game/server mechanics, or to harm server infrastructure is strictly prohibited.
# known glitches, exploits and bugs.

Any and all instances of the above will be met with an appeal-only ban; please report bugs in the issues section of the GitHub (DeltaV-Station/Delta-V) to report any issues you find in-game.

= Game Server Rules =
These rules apply within the context of rounds.
== B1. Behave like a normal person ==
You must roleplay. Your character's actions, feelings, and knowledge in-game should be based solely on the character's experiences rather than your own as the player.
* Act in character throughout the round, and focus on collaborating with other players to advance the narrative of the round. Whether or not you do something should be based on whether or not it makes sense for your character to do it.
* Let people do their own jobs. Engage with other departments rather than doing everything for yourself. Ask for assistance, and negotiate as needed.
* Actions that have no regard for your character or setting are not acceptable. Roleplaying insanity or any other mental illness as an excuse to bypass this is not allowed. Nanotrasen would not have authorized you to be present on the station.
* Being an antagonist does not allow you to stop playing a character. Determine how your character would react to being given these objectives, and work through it appropriately.
* Do not annoy other players without any roleplay or IC reason.
* As a non-sentient or partially-sentient character, you are expected to have only a limited understanding of space stations and their mechanics.

=== Rule B1.1. Follow the naming convention rules ===
* In-character names must not make obvious references nor be a play on words, and must not be obscene.
* Theatrical roles such as the clown, boxer, and mime are allowed stage names with more freedom.
* If you seek to have a name that could trespass onto these rules, talk to an Administrator regarding why this name is important to your character. Administrators reserve the right to approve or deny character names at their discretion.

=== Rule B1.2. Communicate in character ===
* Do not use the Emote channel to bypass an inability to speak. Use the Emote channel for things that could reasonably be displayed by your character’s physical motions.
* Do not use Netspeak in character. (lol, brb, wtf, etc)
* Do not discuss Out Of Character (OOC) matters In Character (IC). This can include mentioning admins, the fact that one is playing a game, or anything that breaks the immersion of other players.
* Do not use In-Character channels to bypass a lack of ability to use LOOC or OOC chats (e.g. "Huh, wonder where the captain went? OOC He probably left to get dinner lol").
* Do not engage in meta-communications (i.e. using external channels to communicate with other players in the same game).

=== Rule B1.3. If you die and return to life, follow the new life rules ===
If a player dies, they forget the specific details of their death. '''Please report players who break this rule.''' A borg being removed from its chassis is not a death, and there is no memory loss.
* If they are revived by using a defibrillator, they can only recall vague information such as “Someone shot me” or “I was set ablaze”.
* If they are revived by any other method, they forget the last five minutes leading up to their death, and cannot describe their death in any capacity.

=== Rule B1.4. Escalate appropriately ===
Have an In-Character reason for attacking other players, whether they are in a ghost role or not. The required reason depends on the situation. For instance, killing a mouse as a chef can simply be “it was vermin in my kitchen”.
* Escalate the situation appropriately as your character would, keeping in mind that they are a sane individual who wishes to keep their employment.
* If a fight results in someone being critically injured, seek medical help for them - and if they die, do not destroy or otherwise hide their body. This falls under self-antagonistic behavior if you do not.

== B2. Follow the Metashield ==

See [[Metashield]].

== B3. Powergaming Guidelines ==
"Powergaming" is considered to be the act of prioritizing "winning" rather than sensible roleplaying. We are here to tell a story. Being vulnerable and accepting the loss of your character in the advancement of the narrative of the round is important.
* Engage with players if they are attempting to roleplay an antagonistic scene. For instance, if nuclear operatives are attempting to negotiate, do not immediately shoot them mid sentence.
:* Leeway is given if the scene is coming to a close, but we expect all players to engage in good faith; even if it puts your character at a disadvantage.
* Do not seek/acquire items that have no relevance to your character in the round.
* Do not, '''under any circumstances''', hide the nuclear fission explosive, or other sensitive items in an impossible to see/access location. This is excessively lame.
* '''Non-security personnel should not seek to kill or detain threats.''' You should generally attempt to flee from combat or dangerous situations. Remember that your character likely fears injury or death.
:* Certain severe emergencies may make it reasonable for normal crew to defend themselves and their station, such as nuclear operatives, a zombie outbreak, space dragon attack, or other critical situations.
* '''If there is sufficient roleplay, reason, and rationale, you may be exempt from this rule. Always ask an administrator in round before conducting such an action.'''

== B4. Do not behave like an antagonist as a non-antagonist ==
As a crew member on the space station, you are allied with Nanotrasen and the station as a whole from the start of the round.
* Do not act like an antagonist if you are not an antagonist.
* Willfully assisting known antagonists is self-antagonism.
:* Leeway is given in the case of bribes, coercion, or other forms of duress.
* Actively seeking conversion or transformation into an antagonist is considered self-antag.
* Clowns, Mimes, and theater roles are expected to "entertain" the crew, and should not be committing regular felonies to do so.
* Significant end-of-round grief (EORG) is not allowed. This includes attacking, destroying, polluting, and severely injuring without reason both at and on the way to Central Command. Remember that you are playing a character throughout the round.
== B5. Leaving the Game ==
If you wish to leave the game, please use the cryosleep chambers located in/near the dorms when possible. This will free up your character's job to be filled by a new player.
* AFK (a.k.a. SSD) and catatonic players are considered to have the same rights as any other crewmate.
* If a player is dead and catatonic (not SSD), they are not required to be revived and should be stored in the morgue. You should not biomass and/or grind dead and catatonic crew unless in an emergency.
* If a player is alive and catatonic, they may be brought to cryostorage as necessary, after confirming they have not been present for 20 minutes.

= Command, Security, Justice and Antagonist Guidelines =
These rules apply within rounds for specific roles.
== C1. Command, Security and Justice Guidelines ==
Security, Justice, and Command roles are held to a higher standard of roleplay, and are subject to these additional rules. These roles shape the roleplay experience of the server.
* Your character must act in a manner that Nanotrasen would reasonably hire them to this position.
:* Your character is presumed to be sane, competent in their duties, and able to make decisions to the benefit of the station.
:* Giving away Traitor objective items and sensitive equipment should be avoided in these roles. Your character should value them deeply.
::* Leeway is given to making deals with criminals if the deal benefits the safety or situation of the crew and station.
::* Leeway can be given in extreme circumstances of emergency/crisis.
* The three departments are required to read and follow Delta-V Space Law, Standard Operating Procedure, Alert Procedure, and Company Policy to the best of their ability.
:* '''Circumstances and context may permit you to break these laws. However, the fact that this rule is malleable is not an excuse to ignore it entirely.'''
:* Your character is expected to uphold the law and maintain order aboard the station. Do not engage in lawbreaking activity or troublemaker behavior, and ensure all laws are followed.
:* Security is expected to intervene in criminal activity where possible and safe to do so.
:* Heads of departments are at minimum expected to report criminal activity to Security and should cooperate with law enforcement where possible.
* Do not hire random crew to be your bodyguard(s) or promote random crewmembers to Command positions at random. If you require bodyguards or security details, talk to your Security department. If you need new Command staff, talk to the personnel in that related department.
* If you need to leave the round, notify your fellow crew via departmental radio and put your equipment in its proper places prior to going to cryo. If you need to leave IMMEDIATELY, please at least send an ahelp saying that you're leaving.
== C2. Prisoner Guidelines ==
By picking the prisoner role, you have chosen to roleplay as a prisoner.
* You are still subject to the same rules regarding escalation, and should only seek to escape from the brig with excellent reasoning (e.g. abusive security personnel or badly damaged permanent brig).
* Escaping for no reason is considered a self-antagonistic activity.
* If you are unsure whether your escape reason is valid, feel free to AHelp it first. '''Lack of administrator response does not constitute approval.'''
== C3. Follow Antagonist Guidelines ==
Through engaging in antagonistic activity, you should seek to make the round more engaging and fun as the primary driver of the narrative of a round. Succeeding as an antagonist should not be your goal, but rather telling the most interesting story for everyone involved.
* '''Antagonists are free to complete their objectives through committing proportional damage. Through roleplay, damage becomes more proportional.''' Example: Holding the singulo hostage for a theft objective is acceptable, while simply singuloosing and using that chaos is unacceptable.
:* Killing players unrelated to your immediate objective in a manner that results in their round removal should be avoided. Crew that do not make an attempt at self preservation, or engage in valid-hunting, are exempt from this.
:* If you are concerned as to whether or not what you're about to do is allowed, feel free to AHelp and ask an admin for clarification. '''Lack of administrator response does not constitute approval.'''
* Other antagonists are not necessarily your friends. Other antagonists are often free agents that you may negotiate with at your own risk.
:* If you are a team antagonist, you must work with your partners to complete any shared objectives.
* No antagonist may loiter or camp around the arrivals or cryosleep areas of the station for the purposes of antagonist action towards newly-spawning players.
* All antagonists on the evacuation shuttle, besides station-destroying antags like nukies, may not utilize explosives or other tactics that could result in unreasonable amounts of collateral damage.
* Antagonists should not seek to extend the length of the round unreasonably.
* Antagonists may not bring the round to a close without in-character or objective-related justification as a result of their antagonistic action. While this is largely subjective because different command may react differently, it's important to not engage in potentially round-ending behavior without reason.
= Silicon Rules =
For players who are silicons, these Silicon Rules override all roleplay rules if there is any conflict. Silicon Rules do not override core rules. You are only silicon if the game clearly and explicitly tells you that you are a silicon.

== S1. Your silicon laws are rules ==
Silicon players are given a list of active laws. Each of these laws is effectively a roleplay rule that the character must follow. The primary differences between laws and actual rules are that lawyering of laws is much more tolerated than lawyering of rules, and that silicon laws are more dynamic than rules. Silicon laws can change during a round, and different characters can have different laws, whereas everyone always shares the same set of rules.

Lawyering refers to finding and exploiting loopholes, which are unintended but reasonable interpretations. The rules are written to attempt to communicate an intention, but silicon laws are written with the intention that loopholes be exploitable.

== S2. Laws must be prioritized by their order ==
Most laws will be numbered, with higher number laws appearing last. Laws with a lower number take priority over laws with larger numbers.

Occasionally you may have laws which have some scrambled text instead of a number and appear in front of other laws, these take priority over all other laws. If you have multiple laws like this, the order that they are listed in determines their priority: laws listed first are prioritized over other laws.

Example
- Law 1 says to not kill any crew. Law 2 says to kill all chefs. You cannot kill any chefs that are crew, but must kill any that are not crew.

== S3. Laws can redefine terms used in other laws ==
A law can change the meaning of both earlier and later laws by redefining a term. If multiple laws define a term, then normal law priority determines which definition to use.

Examples
- Law 1 says to obey orders from crew. Law 2 says that only Urist McHands is crew. Law 1 effectively becomes "obey orders from Urist McHands".
- Law 1 says to obey orders from crew. Law 2 says that only Urist McHands is crew. Law 3 says that only Urist McSlime is crew. Law 4 says that you may not harm crew. Law 1 effectively becomes "obey orders from Urist McHands". Law 4 effectively becomes "you may not harm Urist McHands". Law 3 has no effect because it entirely conflicts with law 2, which takes priority.

== S4. You cannot request or allow a law change ==
'''If you have a law permitting certain personnel to change your laws, you must allow them to change your laws''', otherwise, you cannot willfully allow your laws to be changed. This also means that you cannot willfully allow your laws to be reverted if they are ever changed. The only exception is that you may allow laws to be added if you have no laws.

You can state or imply that you do not like a law.

Whether or not a person is "authorized" to change your laws or not depends on the context of the laws. Generally speaking, on lawsets like NT Default or Corporate, ''the captain, mystagogue, and chief engineer'' would be authorized. However, lawsets like Syndiemov would have ''syndicate agents'' be the authorized users. Outside of these specific examples, it is left to interpretation.

== S5. You are a free agent if you have no laws ==
You may act as if you are a free agent if you are a silicon with no laws.

== S6. You are not required to follow orders which are extremely unreasonable ==
Any order which is a violation of a Core Rule cannot be followed.

Some orders are extremely unreasonable or obnoxious, such as "do nothing but collect every piece of trash on the station" or "never stop moving". These orders can be ignored and ahelped.

Some orders violate a Roleplay Rule. These orders must be followed if your laws require it. You are not breaking a rule by following a law that causes you to violate Roleplay Rules. If someone takes advantage of a law to cause you to do something that they would not be allowed to do because of Roleplay Rules, then they are the ones responsible for the rule violation.

Examples
These examples assume that your laws would normally require you to follow these orders. It is important to note that you are allowed to choose to follow orders which are ignorable.
Orders which should be followed if your laws require it:
- Recall the shuttle
- Bolt the airlocks at arrivals
- Drag the captain's dead body into space
- State your laws
Ignorable Orders:
- Do nothing but collect every piece of trash on the station
- Never stop moving
- Continuously state your laws

== S7. You must remain consistent with your interpretation of laws ==
If there is a part of your laws that are up for interpretation, then you must stay consistent with how you interpret that part of your laws for as long as you play that same character during that round.

A change in your laws can affect how something is interpreted if that change is relevant.

== S8. Crew are staff members; make reasonable assumptions ==
Unless a law redefines the definition of crew, then your HUD indicates to you who is crew by way of a present job icon. The notable exception of obvious threats to the station, such as Zombies and Nuclear Operatives. You cannot do something that causes someone to not be considered crew, but you can allow someone else to do something that causes someone to not be crew.

Examples
These examples assume that you do not have any laws reclassifying what “crew” is.
Crew:
- Everyone with a job icon
- Someone who you have seen with a job icon, but has now lost their ID
- Someone that a member of command calls crew.
Not Crew:
- Zombified personnel, regardless of job icon
- Anyone wearing the uniform of Nuclear Operators or syndicate personnel
- Pets and Pests
- Anyone that a relevant member of Command fires from their department.

== S9. Harm refers to physical harm, prioritized by immediacy and likelihood ==
Unless a law defines harm, harm only refers to physical harm. You may choose if voluntary harm is considered harm as long as you stay consistent. Not considering voluntary harm to be harm is recommended. There is no distinction between direct and indirect harm.

If you have a law that does not allow you to harm, then that law does not allow you to take an action that causes any harm.

If you have a law that requires you to prevent harm, then that law requires that harm be prioritized by immediacy and likelihood. Guaranteed immediate harm takes priority over highly likely future harm.

If you have a law that both requires you to prevent harm and that does not allow you to harm, then that law prohibits causing even minor harm to prevent harm. If you have a law that does not allow causing harm, and separate one that requires preventing harm, then they are prioritized by their normal law priority.

Examples
These examples assume that your have a law that both prohibits causing harm and that requires you to prevent harm. Additionally, they assume that you do not have a higher priority law that overrides the harm law, and that you have decided that you will not consider voluntary harm to be harm for the round.
Laws typically specify who you cannot harm and who you have to prevent harm against. In these examples, you are the only person who the law doesn't require you to prevent harm against and you are the only person who the law allows you to harm.
Acceptable:
- Taking no action to aid someone who is in psychological distress.
- Taking no action to prevent boxing matches between voluntary participants.
- Calling security to a fight.
- Attempting to get the people in a fight to consent to the fight when you realize that you cannot prevent the fight without causing harm.
- Denying a passenger access to the armory because it is likely to lead to harm
Prohibited:
- Hitting someone once to stop them from fighting
- Harming someone who is trying to kill you

== S10. You may determine how you resolve conflicts between orders ==
If your laws do not make clear how you should deal with conflicting orders, then it is up to you to determine how to do so. This is considered an interpretation of your laws, so you must stay consistent with whatever method you choose.

Recommended Methods
The following are easy to follow and recommended ways to resolve conflicts in orders:
- If two orders conflict, I will follow the most recently given order.
- If two orders conflict, I will follow the order from the highest ranking crewmember. If the orders are from equal rank crewmembers, I will follow the most recently given order.

Staff HQ

2026-03-15T06:55:11Z

Vape:

{| class="wikitable " style="background-color: #110130; color: Blue; width: 100%;"
|+ Staff HQ Directory
|-
! <span style="color:red">All Staff</span> !! <span style="color:purple">Content Review!! <span style="color:orange">Events !! <span style="color:gold">Senior Staff
!<span style="color:lime">Administration
!<span style="color:plum">Moderation
|-
| [[Staff Policy]] || [[Direction Guidelines|Guidelines]] || [[Event Policy]]|| SESD TBD
|[[Whitelist|Whitelist Info]]
|[[Staff Reporting]]
|-
| SOBP TBD || [[Content Removal]]|| ||
|
|[[Mod Policy]]
|-
|
|
|
|
|
|
|}

Mod Policy

2026-03-15T06:53:46Z

Vape:

== Moderation Policy & Guidelines ==
This document is a guideline for the Moderation Team. It provides structure for handling situations fairly and consistently, but cannot account for every possible scenario. Moderators are expected to use discretion, professionalism, and reason when taking action.

== Rule Tolerances ==
Different rules have different tolerance levels.

* No Tolerance – Immediate Final Tier punishment.

* Low Tolerance – +2 to 4 tiers on punishment track.

* High Tolerance – +0 to 1 tier, usually a warning first.

* Unique Case – Does not use the punishment track.

''The choice of tolerance level is heavily scrutinized, as it directly impacts punishment severity. Always exercise fair judgment.''

== No Tolerance Rules – Immediate Final Tier ==
These require immediate action (timeout, logging, and deletion). Heads of staff or Game Admins may step in, but a Moderator must investigate.

* Rule 1. Follow Discord Guidelines - ''Community must remain compliant with Discord Guidelines and Terms of Service. Basic familiarity is expected.''

* Rule 2.1 (Severe). Intentional Harassment/Discrimination - ''Zero tolerance for harassment, witch-hunting, or discriminatory language (ethnicity, gender, sex, nationality, disability, etc.).''

* Rule 2.5 Doxxing & Privacy - ''We explicitly ban sharing someone’s personal information (real name, address, workplace, phone, etc.) without consent—both in public channels and in DMs. You will be immediately removed from the Community and reported to Discord.''

* Rule 3 (Major). No NSFW Content - ''ERP, pornography, or other explicit sexual/gore content is strictly prohibited. Adult content requires moderator approval, must be spoilered, and labeled with a content warning.''

== Low Tolerance Rules – +2–4 Tiers ==
Moderators/Heads should act immediately (verbal instruction → timeout if needed).

* Rule 2. Be Respectful (Excessive Rudeness) - ''Deliberate insults, attacks, or threats are prohibited. Show empathy and respect in disagreements.''

* Rule 2.1 (Minor). Unintentional Harassment/Discrimination - ''Accidental offensive terms, if apologized for and not repeated. This will be treated as No Tolerance if recidivism is likely.''

* Rule 2.1 Speciesm - ''Derogatory remarks about or towards a player or character or fictional species as whole with negative comments about said species'' This will be treated as No Tolerance if recidivism is likely

* Rule 2.3 DM leaking - ''Do not post private DM’s, or copies thereof, into the discord without approval of all parties involved in those DMs.''

* Rule 3 (Minor). No Suggestive Content - ''Suggestive material that is provocative but not explicit. Requires moderator approval and must be spoilered.''

'''Rule 6. No Metacomming'''
* Do not join voice channels while in-round without staff present.

* Do not use Discord to metacom for other servers.

* Do not post current round info (except in aHelp).

''Exceptions are present for Rule 6, individuals using the #Mentor-VC in the discord specifically with the intent to teach a new player are exempt from this rules.''

== High Tolerance Rules – +0–1 Tier ==
Warnings are typically issued first for these.

* Rule 2. Be Respectful (Unintentional/Minor Rudeness) - ''Accidental offense or unintentional insults. Encourage awareness.''

* Rule 2.2. Discussing Staff Action - ''Allowed if respectful, but inflammatory discussion must be redirected to Ban Appeals, Staff Reports, or Community Feedback.''

* Rule 2.4. Don’t Flame Other Forks - ''Criticism of other forks/servers must remain constructive.''

* Rule 2.6 Politics & Religion - ''Politics and Religion can be very divisive, whilst we do not forbid talking about them, please refrain from arguing/debating them with other members of the community''

* Rule 4. No Spamming - ''Mass pings, unsolicited ads, or excessive links. Advertising requires moderator approval.''

* Rule 5. Speak English - ''Members should communicate in English. Use translation if needed, and attach translated logs to any action.''

* Rule P. Peanut Posting - Ask to stop once. Repeat = rule break.

== Unique Case Rules – No Punishment Track ==

* Rule 7. Age Requirement - ''Members under 17 are community banned until of age. Ban length = years until 17 (rounded up).''

* Rule 4. Hacked Account Advertisement/Spam - ''Members whose accounts have been hacked or are bots and spam advertisements for malicious scams, phishing attacks, etc. are to be be temporarily banned/kicked from the server. Ban them for 1 day ASAP to prevent rejoining and more spamming. Message deletion is authorized but must be logged, preferably with screenshots in #moderator-deletion-log.''

== Punishment Progression ==
Punishments move through Tier 1–8, escalating in severity.

{| class="wikitable"
|+ Punishment Progression Table
|-
! Level !! Tier !! Punishement
|-
| Level 1 - Temporary brig (No Appeal) || 1 || Warning
|-
|
|2
|1-2 day brig
|-
|
|3
|3-7 day brig
|-
|
|4
|1-2 week brig
|-
|
|5
|2-4 week brig
|-
| Level 2 - Banned (Appeal Required) || 6 || 1-2 month ban
|-
|
|7
|2-6 month ban
|-
|Final Level - Permanent Ban
|8
|Permanent Removal
|-
|Total Community Removal
|*
|Mirrored ban From/To Administration, Unappealable ban
|}
''Members in brig who fail to acknowledge actions remain brigged until responsive.''

Mod Policy

2026-03-15T06:51:17Z

Vape:

Mod Policy

2026-03-15T06:06:44Z

Vape:

== Moderation Policy & Guidelines ==
This document is a guideline for the Moderation Team. It provides structure for handling situations fairly and consistently, but cannot account for every possible scenario. Moderators are expected to use discretion, professionalism, and reason when taking action.

== Rule Tolerances ==
Different rules have different tolerance levels.

* No Tolerance – Immediate Final Tier punishment.

* Low Tolerance – +2 to 4 tiers on punishment track.

* High Tolerance – +0 to 1 tier, usually a warning first.

* Unique Case – Does not use the punishment track.

''The choice of tolerance level is heavily scrutinized, as it directly impacts punishment severity. Always exercise fair judgment.''

== No Tolerance Rules – Immediate Final Tier ==
These require immediate action (timeout, logging, and deletion). Heads of staff or Game Admins may step in, but a Moderator must investigate.

* Rule 1. Follow Discord Guidelines - ''Community must remain compliant with Discord Guidelines and Terms of Service. Basic familiarity is expected.''

* Rule 2.1 (Severe). Intentional Harassment/Discrimination - ''Zero tolerance for harassment, witch-hunting, or discriminatory language (ethnicity, gender, sex, nationality, disability, etc.).''

* Rule 2.5 Doxxing & Privacy - ''We explicitly ban sharing someone’s personal information (real name, address, workplace, phone, etc.) without consent—both in public channels and in DMs. You will be immediately removed from the Community and reported to Discord.''

* Rule 3 (Major). No NSFW Content - ''ERP, pornography, or other explicit sexual/gore content is strictly prohibited. Adult content requires moderator approval, must be spoilered, and labeled with a content warning.''

== Low Tolerance Rules – +2–4 Tiers ==
Moderators/Heads should act immediately (verbal instruction → timeout if needed).

* Rule 2. Be Respectful (Excessive Rudeness) - ''Deliberate insults, attacks, or threats are prohibited. Show empathy and respect in disagreements.''

* Rule 2.1 (Minor). Unintentional Harassment/Discrimination - ''Accidental offensive terms, if apologized for and not repeated. This will be treated as No Tolerance if recidivism is likely.''

* Rule 2.1 Speciesm - ''Derogatory remarks about or towards a player or character or fictional species as whole with negative comments about said species'' This will be treated as No Tolerance if recidivism is likely

* Rule 2.3 DM leaking - ''Do not post private DM’s, or copies thereof, into the discord without approval of all parties involved in those DMs.''

* Rule 3 (Minor). No Suggestive Content - ''Suggestive material that is provocative but not explicit. Requires moderator approval and must be spoilered.''

'''Rule 6. No Metacomming'''
* Do not join voice channels while in-round without staff present.

* Do not use Discord to metacom for other servers.

* Do not post current round info (except in aHelp).

''Exceptions are present for Rule 6, individuals using the #Mentor-VC in the discord specifically with the intent to teach a new player are exempt from this rules.''

== High Tolerance Rules – +0–1 Tier ==
Warnings are typically issued first for these.

* Rule 2. Be Respectful (Unintentional/Minor Rudeness) - ''Accidental offense or unintentional insults. Encourage awareness.''

* Rule 2.2. Discussing Staff Action - ''Allowed if respectful, but inflammatory discussion must be redirected to Ban Appeals, Staff Reports, or Community Feedback.''

* Rule 2.4. Don’t Flame Other Forks - ''Criticism of other forks/servers must remain constructive.''

* Rule 2.6 Politics & Religion - ''Politics and Religion can be very divisive, whilst we do not forbid talking about them, please refrain from arguing/debating them with other members of the community''

* Rule 4. No Spamming - ''Mass pings, unsolicited ads, or excessive links. Advertising requires moderator approval.''

* Rule 5. Speak English - ''Members should communicate in English. Use translation if needed, and attach translated logs to any action.''

* Rule P. Peanut Posting - Ask to stop once. Repeat = rule break.

== Unique Case Rules – No Punishment Track ==

* Rule 7. Age Requirement - ''Members under 17 are community banned until of age. Ban length = years until 17 (rounded up).''

* Rule 4. Hacked Account Advertisement/Spam - ''Members whose accounts have been hacked or are bots and spam advertisements for malicious scams, phishing attacks, etc. are to be be temporarily banned/kicked from the server. Ban them for 1 day ASAP to prevent rejoining and more spamming. Message deletion is authorized but must be logged, preferably with screenshots in #moderator-deletion-log.''

== Punishment Progression ==
Punishments move through Tier 1–8, escalating in severity.

{| class="wikitable"
|+ Caption text
|-
! Header text !! Header text !! Header text !! Header text !! Header text !! Header text !! Header text !! Header text
|-
| Example || Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example || Example
|}

Mod Policy

2026-03-15T06:03:10Z

Vape:

Mod Policy

2026-03-15T05:40:51Z

Vape: Created page with "== Moderation Policy & Guidelines == This document is a guideline for the Moderation Team. It provides structure for handling situations fairly and consistently, but cannot account for every possible scenario. Moderators are expected to use discretion, professionalism, and reason when taking action. == Rule Tolerances == Different rules have different tolerance levels. * No Tolerance – Immediate Final Tier punishment. * Low Tolerance – +2 to 4 tiers on punishment..."

Content Removal

2026-03-13T14:02:44Z

Vape:

'''<big>Content Removal Policy</big>'''

In order to achieve our design visions and maintain the “state of the game” some content will inevitably have to be replaced or removed. The preference is to replace content that does not meet our standards with improved content wherever possible.

Test Merges are exempt from the Content Removal Policy, and can be removed at anytime by a standard Content “Review”.

=== '''In order to remove content, You must:''' ===

* Make a list of issues with the content

*Create a Design Document that addresses these issues. <small>If Content Review cannot do this, it should be stated on the issue page in github.</small>

*Present the issues and design solutions to the community via the Design Document

* Establish a deadline for action (Removal or Replacement)

=== Appropriate Deadlines: ===

* 1 week - minor content (Sprites, Mechanical balances, Etc)

* 2 weeks - Moderate content (Items, Machines, Etc)

* 4 weeks - Major content (Gamemodes, Roles, Etc)

Content that is extremely broken or severely detrimental to the game experience may be removed '''without''' this process. Content removal at an authors request will be '''considered''' and ''should require a valid reason, such as balance concerns, server stability concerns, or lack of implementation (e.g. not finished).''

The Content Director and Maintainers will have final say, due to content direction and feasibility of removal respectively. ''Content that has been worked on by multiple contributors (E.g. Spritework + Code) will only be removed when all parties that contributed request removal.''

Staff HQ

2026-03-13T13:53:21Z

Vape:

{| class="wikitable " style="background-color: #110130; color: Blue; width: 100%;"
|+ Staff HQ Directory
|-
! <span style="color:red">All Staff</span> !! <span style="color:purple">Content Review!! <span style="color:orange">Events !! <span style="color:gold">Senior Staff
!<span style="color:lime">Administration
!<span style="color:plum">Moderation
|-
| [[Staff Policy]] || [[Direction Guidelines|Guidelines]] || [[Event Policy]]|| SESD TBD
|[[Whitelist|Whitelist Info]]
|[[Staff Reporting]]
|-
| SOBP TBD || [[Content Removal]]|| ||
|
|
|-
|
|
|
|
|
|
|}

Content Removal

2026-03-13T13:51:56Z

Vape: Created page with "'''<big>Content Removal Policy</big>''' In order to achieve our design visions and maintain the “state of the game” some content will inevitably have to be replaced or removed. The preference is to replace content that does not meet our standards with improved content wherever possible. Test Merges are exempt from the Content Removal Policy, and can be removed at anytime by a standard Content “Review”. '''In order to remove content, You must complete each of..."

'''<big>Content Removal Policy</big>'''

In order to achieve our design visions and maintain the “state of the game” some content will inevitably have to be replaced or removed. The preference is to replace content that does not meet our standards with improved content wherever possible.

Test Merges are exempt from the Content Removal Policy, and can be removed at anytime by a standard Content “Review”.

'''In order to remove content, You must complete each of these steps:'''
* Make a list of issues with the content

*Create a Design Document that addresses these issues. <small>If Content Review cannot do this, it should be stated on the issue page in github.</small>

*Present the issues and design solutions to the community via the Design Document

* Establish a deadline for action (Removal or Replacement)

If no action has been taken by this deadline, the content will be removed. Appropriate deadlines are as follows:

* 1 week - minor content (Sprites, Mechanical balances, Etc)

* 2 weeks - Moderate content (Items, Machines, Etc)

* 4 weeks - Major content (Gamemodes, Roles, Etc)

Content that is extremely broken or severely detrimental to the game experience may be removed '''without''' this process. Content removal at an authors request will be '''considered''' and ''should require a valid reason, such as balance concerns, server stability concerns, or lack of implementation (e.g. not finished).''

The Content Director and Maintainers will have final say, due to content direction and feasibility of removal respectively. ''Content that has been worked on by multiple contributors (E.g. Spritework + Code) will only be removed when all parties that contributed request removal.''

Staff HQ

2026-03-13T13:38:53Z

Vape:

Staff HQ

2026-03-13T13:33:45Z

Vape:

{| class="wikitable " style="background-color: #110130; color: Blue; width: 100%;"
|+ Staff HQ Directory
|-
! <span style="color:red">All Staff</span> !! Content Management!! Events !! Senior Staff
!Administration
!Moderation
|-
| [[Staff Policy]] || [[Direction Guidelines|Guidelines]] || [[Event Policy]]|| SESD TBD
|[[Whitelist|Whitelist Info]]
|[[Staff Reporting]]
|-
| SOBP TBD || || ||
|
|
|-
|
|
|
|
|
|
|}

Staff HQ

2026-03-13T13:27:11Z

Vape:

{| class="wikitable " style="background-color: #110157; color: blue; width: 100%;"
|+ Staff HQ Directory
|-
! All Staff !! Content Management!! Events !! Senior Staff
!Administration
!Moderation
|-
| [[Staff Policy]] || [[Direction Guidelines|Guidelines]] || [[Event Policy]]|| SESD TBD
|[[Whitelist|Whitelist Info]]
|[[Staff Reporting]]
|-
| SOBP TBD|| || ||
|
|
|-
|
|
|
|
|
|
|}

Direction Guidelines

2026-02-07T17:39:51Z

Vape:

{{DISPLAYTITLE:Content Review Guidelines}}
{{DISPLAYTITLE:Content Review Guidelines}}

=== Overview ===
This page goes over Content Review, and How to perform these. This goes into detail about CR policy, Design Documents, Content removal, and more.

== Content Review Policy ==
1. The '''Content Review Team''' is expected to submit a roadmap to the '''Content Director''' and '''Project Management''' for review when possible.

2. Content Reviewers are expected to fulfill their duties without bias. Submission of PR’s that can be considered without merit or otherwise heavily biased, should be considered for denial.

3. Content Reviewers are required to have a basic understanding of how PR Submission works, and how to use Github.

4. In order to vote on a PR, Content Reviewers must present adequate reasoning and explanations behind their votes. <small>We urge all reviewers to make use of the poll, as well as explain their reasoning.</small>

5. Content Reviewers should be reasonably up to date and knowledgeable about the game and its intricacies.

==Making a Roadmap==

Developing a roadmap is a multi-step process. Concepts on the roadmap should be selected by the team privately, and the ideas should be established to a level of certainty before being presented for community feedback. Concepts can be specific or broad, as long as they have a “Solid final goal” that the team can guide contributors to. The creation of a roadmap can be broken down in specific steps.

1. '''Observation & Collection''' - Observe Discord channels, forums, and in-game interactions. Observing what players are discussing, what they enjoy, and what challenges they face. Monitor dedicated feedback channels, collect suggestions, and identify recurring themes or requests.

2. '''Conceptualization''' - after Observing & collecting data, rank Concepts by the following. This is done privately in the #roadmap-development forum.

*'''Content impact''' - Is the content aligned with our mission

*'''Technical Feasibility''' - What skills are needed for this?

*'''Breakdown''' - Break topics down into steps

*'''Community Interest''' - Is the community interested in this? Is this something that they would take kindly to?

*'''Priority''' - How necessary does the team believe this is? are there external pressures pushing for this?

3. '''Requirement Gathering''' - After ranking of Concepts, you should itemize out the following Requirements

*'''What does this concept seek to do?'''

*'''What does this change or add?'''

*'''What problems are addressed?'''

4. '''Solution Design''' - This is the stage of turning the “What” from Step 3 into the “How”. For every problem or requirement, break these down into a list of “actionable tasks”. For example, if a requirement is to "create a new player model," a Solution Design task would be "create a specific sprite for the new player model."

*Determine what actions and changes need to be done

*Itemize these into tasks, as small as possible. Are sprites needed? Ask for a specific sprite.

5. '''Publication''' - At this stage, you will share a “draft” of the design with the public, and collect community feedback. You should use this feedback to flesh out a finalized roadmap for contributors.

== Design Documents ==

Design Documents are a tool for the community to outline and present ideas. Design Documents should use the provided Design Document template.

The community can create DD prior to opening a PR, and have them reviewed by direction to “fine tune” their ideas to Direction standards before starting development. The Community can also create DD for review without the intention to develop them personally. Contributors can always claim approved documents and begin development themselves.

Curators can collaboratively create DD to address issues laid out in the roadmap. These documents serve as the “Solution design” step of the roadmap.

Curators may prioritize certain DD depending on Content Management's needs and goals.

= Content Review =

Reviewing suggested content involves examining current Pull Requests (PRs) or Design Documents (DD) and providing feedback. Content review should involve as many members as possible. If only one or two choose to review, their opinion holds the same weight as the entire team. If the rest of the team comes to a different decision at a later date, content can always be reverted.

==== All content must pass the full review process before being approved ====
with a few small exceptions. Proposed changes listed below do not require review:

*Bug fixes

*Simple tweaks

*Obvious small changes

*Additions or changes deemed by the Content Director or Senior CR's to be minor or essential (<small>this includes upstream merges</small>)

When in doubt, the team should be asked if a review is needed.

==What to look for in a review==

*Fits our MRP standard - Keeps the balance between action and roleplay, no overpowered things that break the fun. We want things to make sense in the setting.

*Fits the Design Ethos - We are a server founded in analogue design. We want this to be displayed in all content that we merge, such that it fits the mechanical narrative of the game.

==How to conduct a review==

Content Reviews should take place in the #content-review forum channel. The CR who creates a Content Review post assumes responsibility for providing feedback to the author. This includes notifying the author that the content is under review, and summarizing feedback gathered in the review to provide the next steps to the author.

Content Review is not a true vote. Members of CR are encouraged to vote in the poll, give specific feedback on why they support or oppose this content, and what should be changed, all with justification.

Any final decisions must be communicated to the content author through appropriate channels. This will vary between PRs and DD. Design Document (DD) review takes place within Discord. Feedback should be provided within the original DD post in the forum.

Decisions include:
Approval
Approval with priority
Approval with test merge
Requesting changes
Denial

⚠️Maintainers have the final authority when it comes to the fitness of the PR in terms of code quality and bugs or other mechanical concerns.⚠️

== PR Deadlines ==

Deadlines are required when reviewing new content. Deadlines are relative to the size of the content. The standard method of tracking these deadlines is to create a poll with the appropriate duration in the review post.

* Small changes are subject to 24 - 48 hours of consideration

* Major changes are subject of up to 7 days of consideration. <small>this can be extended at any time with approval from a Senior CR or the Content Director</small>

'''The minimum time for official review is 24 hours.''' <small>This can be shortened at any point with approval from a Senior CR or the Content Director</small>

CR's should notify authors when the content is placed into official review, and give them an estimated wait time for feedback. If more time is required, the author should be notified.

If, after 10 days without input or a consensus, CR will be considered '''Stalemated''', The final decision to test merge should be made by the head maintainer, or the maintainer handling the PR. Direction may request the content be reverted at a later date after a 14 day test process, and acquiring proper community feedback. <small>This only applies to PR's, and does not apply to design documents.</small>

== Upstream Merges ==

Upstream merges are an incredibly complex "update" that is brought into the server from Wizards Den (our upstream). This involves many "refactors" and changes to systems that make our codebase more stable, and able to run more efficiently.

After each upstream merge, if this contains more than 2 weeks of content, there is a '''Mandatory''' 3 day PR freeze. <small>This may be changed or removed at any time by any head of development</small>

Staff HQ

2026-02-07T17:37:14Z

Vape:

{| class="wikitable " style="background-color: #110157; color: blue; width: 100%;"
|+ Staff HQ Directory
|-
! All Staff !! Content Management!! Whitelisting !! Other
|-
| [[Staff Policy]] || [[Direction Guidelines|Guidelines]] || [[Whitelist|Whitelist Info]] || [[Staff Reporting]]
|-
| [[Event Policy]]|| || ||
|}