Introduction

This book is intended as a gathering of knowledge by various current and former DeltaV staff members, as well as providing information

Organization

Information about the people and organization between the Delta-V server and codebase.

Staff

All the departments and people in them.

High Command

These are heads of the project and its departments.

Host

Manages the servers DeltaV runs on.

• Skunks

Project Managers

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 managers have the ability to make “Owner-like” decisions via unanimous PM agreements (with other PMs) and can bypass this in times of emergencies.

• Aera Aulin
• Field Command
• Vapetastic / Jimboe

Game Directors

Control the in-game server events made by staff.
Oversight of Event Management; including hiring, training, and promoting. Oversight of Events.

• Cepelinas

Content Directors

Control the direction the game is going in.
Oversight of Content Management; including hiring, training and promoting. Direction roadmap approval, Oversight of Content.

• Stop Sign

Head Moderators

Handles Internal Affairs, investigates staff violations and staff reports. Oversees Moderation, the discord and its rules.

• Glarbog

Head Game Administrators

Oversight of Administration; including hiring, training, and promoting. Administrative rulings and Administrative policies.

• GrayMin
• Halomoth

Head Maintainers

Lead the maintainer team, control the codebase.

• Toby

Head Mappers

Review maps and determine mapping policy and standards.

• Velcroboy

Administration

Make sure the in-game rules are followed.
Lead by Head Game Administrators

Senior Game Administrators

They have more experience than other admins

• Aera Aulin
• BonkTrauma
• Cyberjoel
• HyperionGM
• Solaris
• Vapetastic / Jimboe

Game Administrators

These guys make sure that nobody in-game breaks the rules.

• Charlie Fangtooth
• Cheemsie
• Confused Lemon
• DefundStationSalvage
• Disposable
• Grasstype
• Porto
• PureBreadBagel
• Rebe83
• Rust1954
• Schiene
• Stxcking
• TheGypsyBard
• TurkeyThug
• Wolfmin
• Bunglesnort
• TheFreedomCommander
• Qwerty6981

Trial Game Administrator

Aspiring Administrators

• Devlmin
• shop
• Ponky
• FeelyFunTime

Discord Moderation

These guys make sure that the Discord is nice.
Lead by Head Moderators

Senior Moderators

These guys handle staff report investigations, and keep our discord community clean and fresh

• Userfacethis

Moderators

Everyday Discord mods

• Vapetastic / Jimboe
• Julius FoxMan
• Vlacc

Maintainer Team

Make the game work.
Lead by Head Maintainers

Maintainers

Responsible for making sure that the stuff that gets added works correctly and the code is decent. They review your PRs.

• Stop Sigh
• Toby
• Velcroboy
• Javadocs
• ATaco
• Snickers10m
• BarryNorfolk
• SirWarock
• akesi ma

YAMLtainers

Technically the same as a maintainer but focuses on YAML

• Radezolid

Curation

Make rounds interesting, do events.
Lead by Game Directors

Senior Curators

These guys were here for a while, so they’re more trusted in running and managing events.

• Javadocs
• Stop_Sign

Curators

These guys run cool events.

• Wesk
• Polyeder
• Darkylack
• TurtleOfMan
• DarkEclipse216
• ATaco
• KrissTorrio
• Einknusspringestoast
• Ayylmao69
• AirlineFood
• Sloppr
• Dallas
• Solaris
• Dorragon
• Siphynith
• Novostiya
• RealRobyn
• Inzuno (Kelli Cant)

Trial Curators

Still trying out, aspiring Curators

• Acvu

• Apachito

• Bellwether

• Psylux

• Morgan the Giraffe

Mapping

Guys who make maps.
Lead by Head Mappers

Senior Mappers

Guys who make maps a lot.
May also review maps.

• Field Command
• Colin
• Biddy Gelson

Mappers

Guys who make maps a regular amount

• BonkTrauma
• Graymin
• Turtlemutt
• Requiem
• Bribrooo
• Snowy
• Vapetastic / Jimboe

Maintainers

Changelog Format in Pull Requests

The Changelog section of the pull request must always be at the end of the PR body.
The Changelog always starts off with the Changelog Header, followed by any amount of Category Blocks, which can contain any amount of Entries.

Changelog Header

See source code here

This begins with a case-insensitive :cl:, or the emoji 🆑, followed by any amount of whitespace, then an optional author, which may only contain the characters a-z 0-9 _-,&, and spaces. Localize names to those characters if needed.
If the author part is empty, the name of the GitHub user that opened the PR will be used instead.

Examples:

<!-- Correct -->
:CL:
:cL: Toby, Not-Toby
:cl: Me, Myself & I
🆑

<!-- Incorrect -->
CL:
CL: Toby, Not Toby
:🆑:
:cl: Toby, Töby!!!

Category Block

See source code here

A category block starts off with the case-insensitive name of the category, followed by a colon.
All entries after this until the next category block are part of that category.
Leading whitespace, as well as anything after the colon is ignored.

There is a whitelist of allowed categories, namely:

• Main (This is the default if you do not start off)
• DeltaVAdmin
• Maps

Invalid category names get ignored and the previously set category stays the current one.

Examples:

<!-- Correct -->
MAIN:

maps:

			   DeltaVAdmin:               

<!-- Incorrect -->

mapping:

admin:

DeltaV:

maps::

Entry

See source code here

An entry is a list item, followed by an entry type, then a description. Any leading spaces are ignored.
The entry type has to be one of:

• add
• remove
• tweak
• bug
• fix
• bugfix

Where bug, fix, and bugfix are treated identically.

Examples:

<!-- Correct -->
- bug: Changelogs no longer explode

    *    add:      Nëẅ stüff!! 🐈🐈🐈🐈

<!-- Incorrect -->
bug: Oh no I forgot a list symbol

- delete: We don't have deletions, only removals

* tweak :oops that's a typo on the space and semicolon

Leftovers

Any other line in the changelog block is ignored. You can use this to add comments, whitespace to ease readability, or whatever else you want.

Extra info

Since there are not unique changelogs for every map, unless a change is universal, mapping changelog entries should always be prefixed with the name of the map they apply to.

Example:

- add: Centcomm: Added a new bar

Example

As an example, a full changelog block may look like this:

:cl: Toby, DeltaV-Bot

- add: Added documentation about how to write a changelog block
* fix: Avoid mistakes in changelog blocks

MAPS:

- tweak: All walls have been replaced by bees

No there's no reason not to but this in the first block, but it's a good example :^)
MAIN:
- fix: I forgot to add this changelog entry a few lines above

DeltaVAdmin:
- remove: Removed all admins

How to add missing Changelog Entries

If a pull request was merged without the appropriate changelog entries, you can still add the changelog entries after the fact.

Create a file Resources/Changelog/Parts/{PR ID}.yml

It should be similar to this, but with data appropriate to the PR in question.

author: BarryNorfolk
changes:
- message: Silicons no longer change their battery usage depending on the temperature around them
  type: Remove
- message: IPCs now once again have working alerts for their batteries
  type: Fix
time: '2026-03-06T16:10:00.0000000+00:00'
url: https://github.com/DeltaV-Station/Delta-v/pull/5345

Create a pull request

Request to merge the file. When it is merged, the Changelog bot will parse the file and commit the proper changelog.

PR Review Checklist

This describes the default steps you should do when reviewing a standard content PR

• Read PR description
• Check that requirements are met
• Check that they confirm ownership
  • If it’s a port, confirm that the source is appropriately licensed or confirm that the author gave permission
• Check that the Changelog is Properly formatted
• Start a GitHub review
• Assign yourself to show other maintainers that someone is working on the PR, and to give a person to contact about progress reports
• Review the code, checking quality, sanity, and functionality
  • Test the code locally before merge!! Do not just test that the feature works as intended, try to think of interactions that may break.
• Set the appropriate labels on the PR
  • Remove S: Needs Review
  • Add S: Changes Requested or S: Approved as appropriate
• If the PR already has Direction and Mapper approval or does not need it, it is now free to merge, otherwise wait until it does and merge then

Adminning

Basic Commands

Note

For an overview of admin menus and verbs, check out the upstream Admin Tooling docs

De-/Activating Admin privileges

readmin

deadmin

aghost

Gathering information

adminlogs

adminoverlay

getping

listgamerules

• If the RampingStationEventScheduler is present, the game mode is Survival.
• If the BasicStationEventScheduler is present, you can identify the gamemode by antag-specific gamerules such as Nukeops or Traitors.
• Some round-start antagonists don’t roll immediately; the respective game rules will be shown as [PENDING] until the roles are filled.

lslaws

lsobjectives

lswatchlisted

menuvis

• Use menuvis ALL to view inside closed lockers and other containers by right-clicking.
  • Watch out, people are containers too and you can take out their organs as an aghost!
• Use menuvis without any arguments to go back to normal.

Moderation

adminnotes

ban_exemption_update

• Flag IP: Used to exempt someone from a non-VPN IP Ban. Use this if they are affected by another player’s ban.
• Flag Datacenter: Used to exempt someone from VPN/Datacenter bans.

mute

rename

playerpanel

• Keep a playerpanel open on suspected raiders, it’ll allow you to react much quicker by just clicking the freeze button.

banlist

• By clicking on view, you can display a tooltip with the ID of each ban and other metadata.
  • Do not share the data shown to you in this tooltip, it contains PII.

pardon

• get the ban ID from the ban list

roleunban

• get the ban ID from the ban list

Addressing Bugs

setmind

spawnplayer

• Use this if you can’t teleport someone out of nullspace after deleting their old body. You may need to use setmind to force them in.

griddrag

Warning

Don’t forget to turn griddrag off after using it! There’s no indicator that it’s enabled and you won’t see the grid you’re on moving as you’re moving with it. If you forget to disable it, you’ll probably end up janking around the station and disrupting the round.

• Use this to drag stuck grids away from each other, such as a salvage wreck out of the LPO outpost.
• After executing the command to enable dragging, simply click on the grid you want to pull and hold. You can drag it with your mouse.
• The grid will gain velocity, move your mouse slowly until it’s unstuck.
• Execute it again to disable it.

Eventing

delaystart

• You probably shouldn’t use this frequently or without reason, such as to wait for more players before an event shift or after a server crash.

addgamerule

addaction

loadgrid

• Fly far enough away from the station. If you are too close, the grid might intersect and disrupt the round.

• Open the F3 Menu to get the required values from the debug menu. They’ll be in the topmost block of text.

  

• The grid file parameter should autocomplete, just start by typing /Maps/ and you’ll be able to explore the collection of grids/maps.

• Using the values from the above image, I could spawn in a recruiter shuttle at the location of my aghost as follows:

  loadgrid 4 /Maps/_DV/Shuttles/Admin/recruiter_ship.yml 964 273
  

spawncharacter

• Use this to spawn your CC character with the CentralCommandOfficial loadout.

Miscellaneous

list

help

toggleshadows

• Less straining on the eyes than fullbright while still allowing you to see clearly in most situations.
• Remember to turn this back off before you deadmin to play a ghost role. It won’t be disabled automatically.

setadminooc

• This will persist, you only need to set it once.

fuckrules

Toolshed Commands

General Information

Toolshed commands are invoked as part of their own custom query language. Toolshed allows you to search for certain groups of entities and then apply operations to them.

Important

When you want to use Toolshed, always make sure to start your command by with > .

You’ll get a permission denied message if you don’t do this. Even with the > prepended, you may not have access to some commands. That’s normal.

Selecting entities

You can iterate over certain (groups of) entities with the following commands:

self

• This selects the entity you’re controlling, primarily useful for modifying your aGhost
• For example, you can make yourself able to see health bars using > self comp:ensure ShowHealthBars

marked

• You can store an entity to be selected using this command by right-clicking it and then selecting Admin > Mark entity

entities

Warning

When using the entities command, always make sure you know what you are doing. Double-check your commands. Accidentally applying actions to a large amount of entities could easily end the round or crash the server.

• This allows you to query all entities known to the server.
• You should specify a filter for your query using…
  • with to search for entities that hold a certain Component.
    • For example, you can select all silicons using > entities with SiliconLawBound
  • prototyped to search for entities based on a certain prototype
    • For example, you can delete all puddles using > entities prototyped Puddle delete

ent

• Use > ent <ID> to select a specific entity based on its numeric ID.

Query Recipes

Reopen a specific job slot

> stations:get | jobs:job StationAi | jobs:set 1

• The job prototypes will autocomplete while typing, just replace StationAi if you want to open another job.
• You can also adjust the value using jobs:adjust n, where n can be a positive or negative value.
• When reopening Station AI specifically, you should download the old AI using an intellicard before executing this command. If a player joins while the old AI is still attached to the core, they will spawn as an invisible entity that is unable to move.

List all Silicons and their laws

> entities with SiliconLawBound tee { emplace { var $name ??; ent $value laws:get ?? } }

• the tee here is necessary to ignore the laws:get output and stop the console from being spammed.
• this is certainly not what Toolshed was made for, hence the nested tee and emplace and the debug prints. Don’t look at this as an example of a sane command.

General Recommendations

Make use of cameras!

You can open a floating window which follows a player of your choice around using the camera <username> command or by right-clicking a player and clicking Admin > Open Camera.

They are great for observing multiple people at the same time. I often open cameras on first joins to keep track of what they’re up to while doing other stuff.

Keep the Player list open

The Players tab of the F7 Menu is probably the most useful one of them all.

The player records displayed in the table can be right-clicked to display the same options you would get by right-clicking their character in-game.

Open the Admin Chat in a separate window

The different Admin chat channels provide you with important information about the round. You can use the achatwindow command to open the chat in a separate floating window. This way, alerts and admin messages won’t get buried in comms traffic.

The Console is your friend

You can often get information and perform actions quicker by using Console commands rather than clicking around in the GUI.

For example, tpto <username / entity id> and warp <warp point> allow you to get to where you want to much quicker than using the Ghost Warp menu.

Some essential round info, such as antag objectives, isn’t exposed through the GUI at all.

Local Scripts

You can store series of commands in local files and then execute them ingame using exec <path relative to SS14 Data>

You can simply save text files with commands in the following directory:

Here’s an admin script, for example. It makes sure you’re aghosted, then adds useful components to your ghost and adjusts the speed modifiers such that you move faster by default and at double speed while pressing Shift. It also turns on the admin overlay automatically.

> self not prototyped AdminObserver do "aghost"
> self comp:ensure ShowHealthBars comp:ensure ShowJobIcons comp:ensure ShowMindShieldIcons comp:ensure ShowCriminalRecordIcons comp:ensure ShowElectrocutionHUD
> self do "vvwrite /entity/$ID/MovementSpeedModifier/BaseWalkSpeed 24"
> self do "vvwrite /entity/$ID/MovementSpeedModifier/BaseSprintSpeed 12"
adminoverlay True

By placing it at Space Station 14/data/admin, you’ll be able to execute it by simply typing /exec admin into the chat.

You can also place scripts into subdirectories under data to organize them. Note that file extensions are not ignored here. If your file ends up being saved as admin.txt you’ll have to execute it using /exec admin.txt.

Eventing

Basics Of Eventing

As a Curator (or Admin), you have the power to make rounds more interesting or worse. It is the Curators job to generally respond to players actions or to put players in interesting positions.

Generally, events fall into two types:

Reactive

Responding to faxes, prayers or making something appear from group of players actions, would be a reactive event. These commonly fall under Low Impact or Medium Impact event categories. Usually, staff are improvising on the spot with it.

Proactive

Staff are making scenarios that players have to interact with. Like sending a shuttle to repair for a monetary reward. The size of the Impact various, but usually it could be classified as medium impact.

The Job

In short, your job is to add onto the round with your event. Make it more interesting, make it fun for everyone, not just for yourself.

Don’t be afraid to experiment with ideas, even if they go somewhat poorly. A random, small joke you made with your fellow staff might just lead into an over-blown cinematic ending to the station, which leaves a memorable round for you and for the players. It’s the main enjoyment and goal for any eventer - to make memorable rounds for everyone.

Doing It Right

Of course, making a round memorable (in a good way) is incredibly hard. It generally comes down to forethought, improvisation and restraint. Remember, the best kind of event is a one that players confuse it as a natural occuring thing.

Forethought

The main tactic you can use whenever thinking or doing an event, is considering “what the player would do?” Put yourself in the players shoes:

• What would you do, as a player, if you were faced with this event?
• What about your different characters?
• What would be the worst case scenario?
• What would be the best case scenario?
• If a certain scenario happened, like one of the key members died of your event, what would happen then?
• Could you, as a player playing security, be able to interact with this event during a crisis?
  • What about as a scientist?
  • Maybe there’s no crisis?

It seems daunting at first, and you might catch yourself over-thinking your plan to the point of not wanting to do it, in case of some failure. But this is why you shouldn’t be afraid to experiment. You need to get a grip of this whole philosophy by constantly asking yourself these questions. With enough experience, you will subconsciously take these questions into consideration and be a well adept “storyteller” in no time.

Improvisation

While you might have an overly detailed plan on how things should go, you have to remember that you’re playing a disaster simulator. Things are unpredictable, things can and will go wrong. You’re going to be trying to wrangle some control, while not overly effecting the natural chaos of the game.

This is why it’s generally not advised to write a “script” of what has to happen in your event. While you can control what game mode and scheduler the round has, you cannot predict what players will do with your event. Otherwise, you will usually end up frustrated for things not going your way, which is incredibly discouraging.

Write an event plan of what needs to be done, what things need to be spawned in and what generally is supposed to happen. However, always leave room for improvisation. Have some written up scenarios or expectations of what could happen during your event, but be ready to adapt on the fly.

Restraint

Improvisation is a good skill to have. However, it takes quite a lot of restraint to not go over-board with your ideas.

When you’re eventing, you’re practically trying to find the right balance between too little and too much.

Too much is when you:

• Over-gear your characters with ludicrous amount of supplies just because “it’s what they realistically would carry”, while not taking in account of what they could scrounge up from other departments.
• Seeing your key event figure die due to some understandable reason (like security shooting them for constantly teleporting out of jail due to curator intervention) and angrily or panickingly you revive them several times just to see your end goal.
• Spawning an RPG for someone out of nowhere, because either ghost chat or you thought it would be hilarious for them to go out in a blaze of glory.

Too little is when you:

• Letting your event end early on, because your key figure got hit by a meteor while travelling to the station and you didn’t decide to revive them.
• Abandoning your support for antagonistic group you’ve created on the peak of the stories’ culmination. Like some cultists sacrificing the Captain to you for immense power, while their doors are getting breached by security and not giving the cultists anything for their efforts.
• Not giving appropriate gear to units you’re sending. Like spawning ERT without hardsuits to help out a spaced station.
• Instantly denying on a fax that has a potential interesting plotline for the player to go off from.

Developing the proper restraint generally comes down to experience. However, there are some multitude questions you can always ask yourself:

• Is the action I’m about to do will add anything to the story or detract it?
• Would the players interacting with the event have my input feel fair or reasonable? (Would rejuvenating a dead cuffed prisoner next to a security officer would be fair to the officer?)
• Does the player really need it or can they solve it themselves?

Central Command

Being staff, you gain the fun ability to be Central Command. Unfortunately, we have some rules around being CC.

Your CC character must be a new character.

Your character must be a new character and never join a shift with them. This is to prevent metafriending really. It’s also somewhat weird for others, when you, as an example, were a well-known prisoner who just is now a CC official.

Make a sensible character, someone who reasonably could’ve gotten the position and rank. It can be a desk jockey who spent years in NanoTrasen’s bureaucracy, a nepotism hiree, a security veteran who’s a commander of ERT units or something else you can think of.

NanoTrasen is big, so making up a rank and a position for your character is generally up to you. You can be a normal Central Official, the Supervisor Of Hygiene or Immersive Experience Director and Facilitator. Poke fun at corporatism with your titles and act within their knowledge.

The only unspoken rule is that your in-character rank should reflect your actual staff position. For example, don’t make yourself the Head Director of Central Command if you’re only a Trial Curator. This is just to prevent the weird moments of lower rank officials, who are played by Directors or Project Managers, ordering around their superiors, who are played by Trial Staff.

CC shouldn’t be directly antagonistic to the crew.

With the narrative we hold in DeltaV, Central Command and NanoTrasen aren’t the soulless and evil company just because. They’re more seemingly soulless and evil due to the overwhelming bureaucracy they have to deal first before helping. “Amazon Evil” tier of evilness.

Your character should generally reflect that. While it’s fine to have an egotistical mean character who’s generally in it for the money or power, do keep in mind that in-character, if enough people complained about you, you would get booted off from Central.

You should generally have players fix the problem themselves than the opposite, which is easy to reflect in-game. While you could send in expensive ERT members to fix the station, it is expensive and probably best used somewhere else. So why not gift them some materials and have the engineers that NanoTrasen hired, do their jobs? Cheap, it stays within the budget, and you still help out the crew.

Clarify things and slightly help the crew. Remember, your character probably has to monitor thousands of stations with their own problems. The station that players are playing in are one of them, so act like it.

CC should act within their knowledge.

Generally, while being observing the round, it’s very easy to know what’s going and why it’s happening. However, realistically, Central Command doesn’t, which invites fun scenarios and roleplay.

As Central, you have to roleplay with what information you’re given. The only exception are admin interventions whenever dealing with a Ahelp or a raider. The list of what Central Command has information to is:

• Crew Manifest.
• Crew Health Monitors.
• Station electrical grid system.
• Station atmosphere systems.
• Hearing what announcements are made. (It’s usually better to ignore what they announce.)
• Cameras. (Generally, it’s discouraged to rely on “I saw through the cameras” reason, since it denies a lot of deceit from players. Another reason is why would your character be staring through the cameras, when you have other stations to attend to?)

As a rule of thumb, act as what Station AI can see, except hearing station radio communication. There’s a fun button in the menu to access AI visibility, which shows what you can see through cameras.

If you need more information on what’s going on, request an update from Station Command. You can fax, holocall them for more information, or even announce an update from them.

Don’t over escalate situations, try to get a clear idea of what’s going on as Central. Just because you’ve gotten an independence declaration fax from Captain, doesn’t mean it should automatically result in an Epsilon call. Call Captain, call other Command members, figure out if the problem is an actual real problem. Counterfeit is a real thing!

Rely on people that NanoTrasen hired to do their jobs as well. Order Command to relay messages and command their crew, call Engineering for building related matters, Logistics for purchases, cargo related things and so on.

However, do not shut down antagonists instantly. There are exceptions, where traitors managed to overthrow Command, but if you get a fax about seemingly fake CC members, don’t respond or give them a vague answer that doesn’t instantly validate them as being fake. Antagonists drive the round, so help them out if you feel like it.

Limit and keep your announcements professional.

Announcements are generally good to let everyone know what’s going on. They’re fine to use for emergency related things or incredibly niche things, like informing about a bill for crewmember teleportation out of an FTL flight.

However, keep in mind that the more common announcements are, the less players are going to read them. It’s why you should generally try to convey information through holopad calls or faxes. Command’s job is to command, so trust them to relay your information correctly. If you can’t decide if this requires an announcement, ask your peers for help.

Another note is that you should try to keep your tone professional as Central Command. Your position is valued highly, so act like it.

In short, avoid announcements like these:

• “Central Command announcement:”
  • “guys what the fuck are you doing there holy shit”

And have them more like:

• “Central Command announcement:”
  • “We’ve been observing the on-going situation and ask the crew to calm themselves. Otherwise we will have to take extreme measures.”

ERT

Emergency Response Teams are specialized elite units of NanoTrasen. Trained to handle any emergency, they’re a fearsome enemy to anyone who opposes the company.

Unfortunately, all the good ones are too busy saving company stocks. The lackeys are going to have to pull their weight.

ERT are staff spawnable ghost roles for players to play. They’re usually used to help out the crew whenever their odds are incredibly against them. Though, eventers also tend to use them for CC inspections or other events.

There are several levels of ERT:

• Amber
  • They’re more designed for regular station activities, non-emergency. They come with an APC and basic handguns + disablers.
• Red
  • Designed to respond to emergencies. They come with their own hardsuits and specialized gear. Should be generally the standard for deployment.
• Gamma
  • Designed to respond to extreme emergencies. Come with even stronger gear. They are, however, should generally be limited to deploy under extreme circumstances (there are barely any crew left or the odds of survival for ERT are abysmal.)

There are also several specializations of ERT:

• Leader
  • They are, as the name implies, the leader of their squadron. Their job is to manage their squad, manage the crew and follow Central Command’s orders. They’re also allowed to be picked by eventers themselves, if there are no available ghost to possess them.
• Security
  • Combat units. Their purpose is to be the ones killing the threat, or delaying them long enough for the primary mission to succeed. They’re equipped with the heaviest armaments, with player chosen loadouts.
• Engineer
  • Engineering units. Equipped with a special RCD, they’re designated to repair the station or ensure evacuation is properly sealed and repaired for efficient repairs. However, equipped with lesser firearms, they’re not great at dealing with threats head on. Send them to fix stations.
• Medical
  • Provide healthcare to their teams or crew. Equipped with medical equipment, which gets stronger depending on their level, they’re designated to either heal the wounded on evac/midpoint, or be medics to their team. If they don’t die first, they’re an invaluable unit to their team, due to them having incredible strong meds to instantly patch up any wound.
• Chaplain
  • Dispel any glimmer or cultist activity. While they’re not well-equipped for combat, they are, however, ready to de-convert any possessions or deal with any ghostly haunting. Don’t send them to deal with Colossus though.
• Janitor
  • The strongest unit of the team. Equipped with only The Mop and a grenade launcher loaded with cleannades. Any filth, living or dead, fear their name. They do not need any fancy guns, only the mop is a viable weapon. Due to that, Central Command holds them in their highest regard.
• CBURN
  • Biological contamination units. They’re mainly designed to fight with zombies, due to them coming with free cures and equipped with incendiary rounds. Send them whenever zombies overrun the station or have to deal with diseases.
• SRT
  • Special Response Team, designed for riot control or threat extermination. Usually spawned in during Epsilon or a major antag takeover attempt of MidPoint. Do not deploy them without Senior Curator permission.

Try deploying them in a group, specialized to combat the specific emergency. If it’s some sort of medical emergency, spawn a couple of medical units, alongside a security and a leader to ensure no further casualties occur. If it’s an engineering problem, spawn a couple of engineers, alongside a doctor to treat the wounded if needed.

While their gear is usually good enough to combat the problem, sometimes giving additional tools or supplies might be helpful. For emergencies like singuloose, it’s better to spawn in de-accelerators for engineers, since they don’t come equipped to combat this specific scenario. However, avoid over-gearing them as well. This usually applies to ERT security, by giving them extra medicine or weapons. In most cases, they don’t really need it.

Emergency Call

If the station is in trouble, eventers can send ERT to help out the crew. Though we have strict conditions WHEN to spawn them, due to their effect on antagonists. Luckily, we have a chart to simplify our system:

Regular ERT Chart:

WarOps ERT Chart:

The premise is that you’re trying to strike a balance between crew and antagonists. If there are nukies, and they wiped the crew under 1 minute, it might be fine to send in ERT to prevent a super easy and cheesy win. But if they fought like hell through the crew, it might not be wise to rob them from their victory.

In most cases, someone will complain about your decision of sending ERT, but don’t let that discourage you! Some general questions you can ask yourself to decide if it is worth sending them in:

• Will this add anything to the round?
  • If you think that deploying your units to the station might add to the overall story of the round, do it.
• Would this pose as an unfair battle to the major antagonist?
  • If, say, a dragon swooped in, and you got a fax about their attack, view how much damage the dragon is causing. If they managed to overrun the station with their carp flood, give them a hand at evacuation with security units. If you can think that security and crew can manage it on their own, maybe don’t send it, or give send them some supplies.

Trust your judgement. If you can’t, ask other staff for help.

Sending Them In

You have two choices in how you can send them in.

• The Evacuation Shuttle
  • A classic choice and simple. If the crew called in evacuation, you can spawn in the incoming shuttle and have them prepare (or call in an earlier evacuation yourself, but refrain from this). However, the con of this, is that usually, ERT has a minimal impact on the situation. They either become door guards or extra doctors to help out with the wounded.
• The Separate Shuttle
  • You can either spawn in a shuttle using commands or using the CC shipyard console to grab yourself a shuttle. This method allows you for a non-evacuation shuttle deployment and possibly send in your guys much earlier than expected. However, if you’re trying to time it with an evacuation shuttle, chances are, they will deploy around the time evacuation leaves. This is mainly due to the time it takes for ghost players to take the role, figure out their loadouts and deploy on the station.

Non-Emergency Call

In the case you need an ERT member for some event, spawning them in is also fine. They’re most commonly used to be bodyguards for important CC members, but other various uses can be found for them, like sending them in for a special package recovery mission.

Take into consideration what threat level or what type of scenario you’re taking them in. You don’t want Gamma units walking around for a simple protection job of an inspector. That would be waste of money and make antagonists lives much harder.

Tips

Responding to Prayers and Faxes

Faxes

• If someone sents a fax to Central Command, you will receive the following notification in admin chat and hear a printing sound effect.

  

• Warp to CC using warp Centcomm to take a look at the fax.

• Instead of spawning in your CC character for each announcement, you can simply take the ID out of your Admin PDA and set it to your character’s name; it works just like an Agent ID, allowing you to announce while staying aghosted.

  

Spawning in as CC anyway

• In some situations, you may want to holocall the station. Or perhaps you just prefer doing things as an actual character. You can spawn in your CC character using spawncharacter <character name> CentralCommandOfficial

Prayers

• If someone prays, you will receive a notification like this in admin chat:

  

• Teleport to them using tpto <username> to see if they’re offering anything in exchange or engaging in roleplay. It may make you reconsider answering their prayer.

• If you decide to answer their prayer by spawning something, you can place it in a smoke cloud or bluespace flash for dramatic effect. You can spawn these effects using the Entity panel, opened using F5. Search for “instant” and they should appear; they’re spawned by clicking like any other entity, though you won’t see a preview.

  

Warning

The range on the Gravity Well instant effect is very large, able to affect all of your admin area if placed in its center. You probably shouldn’t use it in response to a prayer.

Building Stuff

Placing entities/tiles in a rectangular shape

• To easily place many tiles or entities at the same time, select what you want to place and hold CTRL while clicking on the first corner. Then release CTRL and move your mouse to select the second corner. Click the second corner without holding CTRL.

  • This only works when placing tiles/entities aligned to the grid. If you want to place a bunch of entities that are normally placed freely, select SnapgridCenter or SnapgridBorder in the dropdown menu of the spawn panel.

    

Removing the clouds from a planet map

When loading into a planet map, it’ll be covered by clouds like this:

1. Open F7’s Objects tab and select Maps in the dropdown, then open VV on your map
2. Find and delete the RestrictedRangeComponent

Tricks

Arbitrary Flatpacks

You can create flatpacks any Entity. This can, for example, be used for answering faxes or chelps asking for specific vendors that weren’t mapped.

1. Spawn any flatpack using the F5 panel, then open VV on it.

2. Find the FlatpackComponent and open it

3. Set the Entity attribute to whichever Entity you want to be spawned.

4. Rename and redescribe it using the verb under Tricks

aGhost Shenanigans

Changing your aGhost sprite

Using Toolshed

> self comp:ensure ChameleonDisguise do "vvwrite /entity/$ID/ChameleonDisguise/SourceProto MobRevenant"

• Replace MobRevenant with any prototype you want.
  • You should scale yourself down if you choose a large prototype like the Honkmother to make sure your aGhost isn’t disruptive.

Manually

1. Open the VV GUI on your aGhost.
2. Add the ChameleonDisguise component to yourself.
   • Make sure you use the ChameleonDisguise component, not the ChameleonDisguised component.
3. Right-click yourself to check your Entity ID.
4. Use the following console command, replacing ID with your entity 1337 and MobRevenant with a prototype of your choosing:
   • vvwrite /entity/1337/ChameleonDisguise/SourceProto MobRevenant

Stopping the Jittering

While some prototypes work just fine when orbiting players, others will jitter and teleport around as players face new directions. To stop this from happening, set the _noLocalRotation attribute of your TransformComponent to True. You can check the box in the VV GUI or use the following Command:

> self do "vvwrite /entity/$ID/Transform/_noLocalRotation true"

Before setting _noLocalRotation, turn to so the sprite you want is displayed. _noLocalRotation will lock your sprite rotation completely (relative to the grid).

Making ghosts RGB

• Simply add the RgbLightController component to the ghost in question.

Station Comms in a Ghost Bar

Warning

Don’t give ghost bar patrons access to station comms, they will be able to send messages to the station. This is meant to be used to give your character at a ghost bar or other admin area event access to comms, so you can keep track of what is happening on station.

Why?

After a building a ghost bar, you may find yourself wanting to join in and interact with some of the ghosts there. Taking one of the Custom Roleplay Role slots you created will leave you unable to hear the station’s comms, but you can modify your radio to listen in while making sure that nobody else can easily steal it while you’re aghosted to take care of something.

How?

1. Open View Variables on your radio.

2. Find the ActiveRadioComponent under Server Components set both GlobalReceive and ReceiveAllChannels to True

   • This will allow you to hear all comms channels

   

3. Add the UnremoveableComponent to it

   • This will stop anyone who tries to remove it.

Sending Custom Mail

1. Spawn a storage container in your admin area. In this case, I’ll be using a bag of holding. Take note of its Entity ID.

   

2. Put everything you want shipped into the container. It can be multiple items at the same time.

   

3. Find the entity ID of the character you want to send them to.

   

4. Execute the command as follows:

   mailto <recipient id> <container id> <fragile?> <priority mail?> <large?>
   

   • Large mail is shipped in packages

   • Continuing with our example, I’ll run the following:

     

   • The package will be spawned at the mail teleporter to be delivered by the couriers