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

Manage the DeltaV team as a whole.

• Aera Aulin
• Field Command
• Jimboe

Game Directors

Control the direction the game is going in.

• Cepelinas
• Stop Sign

Head Moderators

Lead the Discord moderation team.

• Glarbog

Head Game Administrators

Lead the in-game administration team.

• GrayMin
• Halomoth

Head Maintainers

Lead the maintainer team, control the codebase.

• Toby

Head Mappers

Review maps.

• Velcroboy

Administration

Nake 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
• Jimboe
• Solaris

Game Administrators

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

• Cheemsie
• Confused Lemon
• DefundStationSalvage
• Grasstype
• Porto
• PureBreadBagel
• Rebe83
• Rexy
• Rust1954
• Schiene
• TheGypsyBard
• TurkeyThug
• Wolfmin

Trial Game Administrator

Aspiring Administrators

• Bunglesnort
• Charlie Fangtooth
• Disposable
• GlitchesBrew
• Stxcking

Discord Moderation

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

Senior Moderators

Lots of days Discord mods

• Userfacethis

Moderators

Everyday Discord mods

• 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
• Quanteey
• Snickers10m

Curation

Make sure rounds are interesting, do events. Review content additions to ensure they fit the direction.
Lead by Game Directors

Senior Curators

These guys make sure that nobody in-game breaks the rules, and have been for a while.

• Javadocs
• JohnHelldiver

Curators

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

• Porto
• Wesk
• Polyeder
• Darkylack
• TurtleOfMan
• DarkEclipse216
• ATaco
• KrissTorrio
• Einknusspringestoast
• Ayylmao69

Trial Curators

Still trying out, aspiring Curators

• Rebe83
• Schiene
• Solaris
• Dallas
• Sloppr
• Quill
• AirlineFood
• Dorragon
• Quanteey

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

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

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

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.

lsobjectives

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.

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: |OS|Location| |–|—| |Linux|~/.local/share/Space Station 14/data/| |Windows|%APPDATA%\Space Station 14\data\| |macOS|~/Library/Application Support/Space Station 14/data|

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.

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