Delta-V Wiki - Recent changes [en]

Server Rules

DV tne7034 — Sun, 23 Aug 2026 03:00:37 GMT

Updated section S8 to be in line with actual server rules

← Older revision		Revision as of 23:00, 22 August 2026
Line 232:		Line 232:

	== S8. Crew are staff members; make reasonable assumptions ==		== 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.		Unless a law redefines the definition of crew, then crew is considered the employees of the station, with 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		Examples
	These examples assume that you do not have any laws reclassifying what “crew” is.		These examples assume that you do not have any laws reclassifying what “crew” is.

	Crew:		Crew:
	- ~~Everyone with a job icon~~, even ~~Assistants/Passengers~~		- Anyone employed by the station, even assistants
	~~- Someone who you have seen with a job icon, but has now lost their ID~~		- Someone that a member of command calls crew
	- Someone that a member of command calls crew.
	Not Crew:		Not Crew:
	- Zombified personnel~~, regardless of job icon~~		- Anyone not employed by the station
	- Anyone wearing the uniform of Nuclear Operators ~~or syndicate personnel~~		- Zombified personnel
			- Anyone wearing the uniform of Nuclear Operators
	- Pets and Pests		- Pets and Pests
	- Anyone that a relevant member of Command fires from their department.		- Anyone that a relevant member of Command fires from their department

	== S9. Harm refers to physical harm, prioritized by immediacy and likelihood ==		== S9. Harm refers to physical harm, prioritized by immediacy and likelihood ==

Reviewing Content With Ethos

DV vapetastic — Fri, 21 Aug 2026 23:16:53 GMT

Checks and Balances

← Older revision		Revision as of 19:16, 21 August 2026
(2 intermediate revisions by the same user not shown)
Line 14:		Line 14:
	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>		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.'''		5. '''Reviews placed at any time that are derogatory or insulting to the creator and/or content 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>		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>
Line 22:		Line 22:
	== Checks and Balances ==		== 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>		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 that is viewable by staff.''' <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. If a reversal / decision is made by High Command that goes ''against'' CR's decision, there should be a detailed explanation as to why, as well as addressing any major concerns that were brought up during the CR process by reviewers.</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>		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>

	3. '''Maintainers can deny a PR or feature based on, but not limited to, short- or long-term maintainability concerns, performance concerns, unfixable bugs with implementation, and server stability concerns, regardless of CR’s or High Command’s decision.''' <small>Maintainers must provide analysis, metrics, incidents, bug reports, or any other documentation to support their decision. (aka there has to be a functional reason, they cannot deny because they don’t like it)</small>		3. '''Maintainers can deny a PR or feature based on, but not limited to, short- or long-term maintainability concerns, performance concerns, unfixable bugs with implementation, and server stability concerns, regardless of CR’s or High Command’s decision.''' <small>Maintainers must provide analysis, metrics, incidents, bug reports, or any other documentation to support their decision. (aka there has to be a functional reason, they cannot deny because they don’t like it)</small>

Administrative Rulings

DV disposablecrewmember42 — Fri, 21 Aug 2026 20:01:46 GMT

revert beacon ruling for now, under discussion again

← Older revision		Revision as of 16:01, 21 August 2026
(One intermediate revision by the same user not shown)
Line 7:		Line 7:
	** 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.		** 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.		** This ruling was put in place because there is no functioning Borg death system.
			* Antagonists <span style="color:red">may not</span> stall the round by repeatedly recalling the shuttle. {{AnchorLink\|antag-stalling}}
			** Antagonists <span style="color:green">may</span> recall the shuttle exactly once if it helps them accomplish their objectives.

	=== Antagonistic Ghost Roles ===		=== Antagonistic Ghost Roles ===

Staff Policy

DV vapetastic — Thu, 20 Aug 2026 00:48:05 GMT

High Command Staff

← Older revision		Revision as of 20:48, 19 August 2026
(4 intermediate revisions by the same user not shown)
Line 21:		Line 21:
	''This breaks down each staff rank, their duties, and permissions. Higher ranking staff members, in their respective departments, gain all permissions of lower staff ranks.'''		''This breaks down each staff rank, their duties, and permissions. Higher ranking staff members, in their respective departments, gain all permissions of lower staff ranks.'''

	=== ~~Head~~ Staff ===		=== High Command Staff ===

	'''Project Manager (PM)'''		'''Project Manager (PM)'''
	- Handles Internal Affairs, ~~content~~, ~~staff policies~~, and all things regarding Delta-V. Oversees all staff. Determines the continuity of the project. Determines the “Future Plans” of the project. ''Project ~~manager’s~~ have the ability to make “Owner-like” decisions via unanimous PM agreements (with other PM’s) and can bypass this in times of emergencies.''		- Handles Internal Affairs, Content, Staff Policies, and all things regarding Delta-V. Oversees all staff. Determines the continuity of the project. Determines the “Future Plans” of the project, and ensures that the Ethos is maintained. PM's are responsible for Massive content that will determine the function / goal of the server. They take precedence and are the determining factor when something crosses over multiple departments. ''Project Manager’s have the ability to make “Owner-like” decisions via unanimous PM agreements (with other PM’s) and can bypass this in times of emergencies.''

	'''Head Moderator'''		'''Head Moderator (Head Mod)'''
	- Handles Internal Affairs, Investigates staff violations and staff reports. Oversees Moderation, the discord and it's rules.		- Handles Internal Affairs, Investigates staff violations and staff reports. Oversees Moderation, the discord and it's rules. Arbitrates any situation involving 2 or more heads of staff, and is responsible for being the non-biased party.

	'''Head Game Administrator (HGA)'''		'''Head Game Administrator (HGA)'''
	- Oversight of Administration; including hiring, training, and promoting. Administrative rulings and Administrative policies		- Oversight of Administration; including hiring, training, and promoting. Administrative rulings and Administrative policies. Works with the Game Directors to ensure In-game standards are upheld

	'''Game ~~director~~ (GD)'''		'''Game Director (GD)'''
	- Oversight of ~~Direction~~; including hiring, training, and promoting. ~~Direction roadmap approval~~, Oversight of ~~Content~~.		- Oversight of Events; including hiring, training, and promoting Curators (Eventers). Works with the HGA's to ensure In-game standards are upheld

			'''Content Director (CD) -''' Oversight of Content Review (CR); including hiring, training and promoting Content Reviewers. Ensures that Ethos is maintained.

			'''Head Maintainer (HM)''' - Oversight of the codebase, including hiring and training maintainers, and moderation of the Github. Oversee's all contributors or those active on the github, and can grant or remove access to the github at anytime.

			'''Head Mapper''' - Oversees all maps in the codebase, can assign and revoke Mapping Maintainer privileges from Map Maintainers, and oversees promotions of Senior Mappers. Determines all mapping standards.

			'''Host''' - Manages the game server, handles any "Real-time" issues related to the game servers.

	=== Senior Staff ===		=== Senior Staff ===
Line 58:		Line 66:

	'''Curator'''		'''Curator'''
	- Events, Chelps, Event creation, Banning Raiders, Event Approval (via event policy~~). Content approval (via vote~~).		- Events, Chelps, Event creation, Banning Raiders, Event Approval (via event policy).

	'''Trial Curator'''		'''Trial Curator'''
	- Events, Chelps, Event creation~~, Banning Raiders, Content approval (via vote)~~.		- Events, Chelps, Event creation.

	'''Trial Administrator'''		'''Trial Administrator'''
	- Ahelps, Notes & Bans, Rule Clarifications, and Ban Appeals.		- Events, Ahelps, Notes & Bans, Rule Clarifications, and Ban Appeals. Event Approval (via event policy).

	~~== 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.'''~~
	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.

	~~'''2. Never use a “smite” against a player character that is in round.'''~~
	~~This includes possible raiders. Smites have the capacity to be irreversible and game breaking. They should not be used outside of the admin arena.~~

	~~'''3. Events should be allowed to play out at their own pace.'''~~
	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.

	~~'''4. Events must meet or exceed our MRP Standard.'''~~
	~~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.~~

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

	~~'''6. Events should never portray NanoTrasen or Central Command as directly antagonistic to the crew.'''~~
	~~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.~~

	~~'''7. Events should not disrupt the balance of the round.'''~~
	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.

	~~'''8. Event roles should be reserved for players.'''~~
	~~Staff are expected to organize and oversee the event, not partake in it. If a ghost role is not taken for more than 5 minutes, the eventing staff member may join the queue .~~

	~~'''9. aGhosts are welcome to take any ghost roles.'''~~
	~~Refer to the previous rule regarding roles you have spawned.~~

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

	~~'''11. You may not take ERT Leadership roles unless 5 minutes has passed without anyone taking the role.'''~~
	~~Any spawned CC character going to the station, must be armed by security on station. If your character is visiting the station, You are Not Allowed to spawn weapons for them~~.

Reviewing Content With Ethos

DV vapetastic — Wed, 19 Aug 2026 23:36:35 GMT

← Older revision		Revision as of 19:36, 19 August 2026
Line 25:		Line 25:

	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>		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>

			3. '''Maintainers can deny a PR or feature based on, but not limited to, short- or long-term maintainability concerns, performance concerns, unfixable bugs with implementation, and server stability concerns, regardless of CR’s or High Command’s decision.''' <small>Maintainers must provide analysis, metrics, incidents, bug reports, or any other documentation to support their decision. (aka there has to be a functional reason, they cannot deny because they don’t like it)</small>

User:DV tne7034

TNE — Wed, 19 Aug 2026 19:49:02 GMT

TNE deleted the user account "DV tne7034" (209)

User:TNE

TNE — Wed, 19 Aug 2026 19:49:02 GMT

TNE merged the user account "DV tne7034" (209) into TNE (202)

User:DV tne7034

TNE — Wed, 19 Aug 2026 19:49:00 GMT

TNE changed group membership for DV tne7034: revoked bureaucrat, projectstaff and administrator

Event Policy

DV disposablecrewmember42 — Wed, 19 Aug 2026 18:28:59 GMT

Reverted edit by DV disposablecrewmember42 (talk) to last revision by Vape

← Older revision		Revision as of 14:28, 19 August 2026
(One intermediate revision by the same user not shown)
(No difference)

File:ERT chart.jpg

DV disposablecrewmember42 — Wed, 19 Aug 2026 17:28:55 GMT

DV disposablecrewmember42 uploaded a new version of File:ERT chart.jpg Taken from Google doc, I hope it was kept up-to-date. The previous file became suddenly unavailable.

New page

a chart describing the standard for summoning ERT

Staff HQ

Vape — Tue, 18 Aug 2026 19:34:10 GMT

← Older revision		Revision as of 15:34, 18 August 2026
Line 15:		Line 15:
	\|-		\|-
	\|		\|
	\|		\|[[Reviewing Content With Ethos\|Ethos Reviews]]
	\|		\|
	\|		\|

Reviewing Content With Ethos

Vape — Tue, 18 Aug 2026 19:33:30 GMT

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

← Older revision		Revision as of 15:33, 18 August 2026
(2 intermediate revisions by the same user not shown)
Line 1:		Line 1:
	<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>		<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 ==		== 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.		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>		</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>		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>		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.'''		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.'''

	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. '''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>		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 ==		== Checks and Balances ==

Reviewing Content With Ethos

Vape — Tue, 18 Aug 2026 19:09:39 GMT

Establishment of Ethos Guidelines

New page

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.

== Ethos Policy ==

1. '''Content reviewers will review all content against the expectations of Ethos.''' 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.


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

3. '''Reviews can and should be made against ethos when it is in the best interest of the community, or content.''' 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.

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.''' 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.

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.''' 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. 

== 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''' 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.

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.''' Any denial formed by content review, must disclose the option to appeal.

Staff HQ

Vape — Tue, 18 Aug 2026 18:40:04 GMT

Expansion of the table

← Older revision		Revision as of 14:40, 18 August 2026
Line 13:		Line 13:
	\|[[Administrative Rulings]]		\|[[Administrative Rulings]]
	\|[[Mod Policy]]		\|[[Mod Policy]]
			\|-
			\|
			\|
			\|
			\|
			\|
			\|
	\|}		\|}

Administrative Rulings

Vape — Tue, 18 Aug 2026 18:39:03 GMT

Updates from pink skunks to ping host

← Older revision		Revision as of 14:39, 18 August 2026
Line 1:		Line 1:
	{{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 ~~Skunks~~ 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}}		{{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 ==		== Concerning antagonists ==