User:SpaceSmithers/guide sandbox

This page is currently under construction! The following page is currently in the process of being created, is undergoing a major structural rework and/or is being moved. The reason for this is: "This is a sandbox to make incremental edits to incorporate san7890's improved guide to mapping. Absolutely everything is subject to change, and I encourage you to overwrite literally anything. Editors note: standardize linking all headers to the respective HackMD headers so that readers absolutely can not miss it."

Other related guides: Understanding SS13 code, SS13 for experienced programmers, Guide to door access and Map Merger

Read this! This page is mostly port of san7890's A-Z Guide to Mapping, a HackMD document that details the mapping essentials. It is recommended that you read that document first as it is well organized, updated, and contains very useful visuals that this page may lack. If you are an experienced mapper, san7890's Mapping Reference Collection may be more useful to you.

Big Chungus says: "Nyehehehehe I'm Big Chungus (big chungus voice). I just went through some stuff and left some comments. If you want something nice to write about the Guide to Mapping (and the Mapping Reference Collection) in those above chat bubbles, I like Goonstation ZeWaka's Prompt (inspired probably by san7890's own words), which can be found here: https://hackmd.io/@goonstation/maps#Goonstation-Mapping-Guide ."

Getting Set Up

Setting up before doing anything is crucial to having a smooth and painless mapping experience.

Mapper's Checklist

Listed below is the software we'll be using:

• Git (Windows)
• Github Desktop (and a GitHub Account)
  • You may substitute this for any Git client that you know how to use already (Bash or GitKraken). If you do not know how to use any Git client, Github Desktop remains a perfectly acceptable client for mapping changes, and I will be using it throughout this guide.
• StrongDMM Map Editor (available for Windows, Linux, and MacOS)
  • If you prefer to use a web-based utility, you may use FastDMM2. Never, ever use Dream Maker to map. You will only harm yourself.
• Visual Studio Code with the Goonstation Extension Pack
  • This is recommended because you will need to test your mapping changes! In the words of MMMiracles (creator of Cere, Donut, and Tram): “Knowing how to code greatly expands your mapping horizons.” You will not need to know how to code in order to map but having this set up at the very start will greatly assist your future endeavors!
  • We use the Goonstation Extension Pack for easy interaction with BYOND’s Dream Maker code, it is a must-have. Don’t fret the name (because /tg/ coders made most of the stuff anyways haha).
• Python
  • This is needed for Git Hooks, which are important in your mapping endeavors.
• Love

It is imperative that you use the Map Merger tools before committing any changes to a map. See here for how. Some modern programs do similar functions to what Map Merger does, but running this and getting your Git Hooks set up save you a lot of headache.

Forking the Repository

Firstly, you need a fork. A fork will be your very own copy of our repository, free do with as you wish! Just hit the "Fork" button on https://github.com/tgstation/tgstation. Feel free to be creative with the name of your fork. Displayed should be "(GitHub username)/(name of fork), forked from tgstation/tgstation",It should look something like this: .

Within your fork, you'll want to click the "Code" button, then click "Open with GitHub Desktop" (assuming you've downloaded it) under the dropdown. A prompt from the application will open; find a clean folder to locally copy your repository and click Clone. This may take a few minutes. Another prompt will appear asking: "How are you planning to use this fork?" You will want to select "To contribute to the parent project". This will make creating Pull Requests easier.

Branching the Fork

GitHub Desktop should look something like this

The final part to setting up GitHub is to make a new branch. This part is super-duper important, because you want to keep your “master” branch on your fork as clean as possible, since it’s a pain to clean out and send pull requests to.
To do this, click on the Current branch (which defaults to "master") and click on the "New branch" button next to the filter bar. For every individual project you work on and submit a Pull Request for, you want to be on a brand new branch. Feel free to name it whatever you want, can be as goofy or as organizational as you want. It’s your fork, after all.

You may also get a screen that says “base it off the current branch” or “base it off the upstream/master”. That depends on what you want, but if you want to start fresh on a new project, always hit “base it off the upstream/master”.

Mapping: San7890's Guide to StrongDMM

Preamble

In the time of Metacide, the creator of MetaStation and the last person to make a "Guide to Mapping", all that you had was Dream Maker's program. Dream Maker sucks though, and we have better tools. While all of the content you see on the rest of this page and elsewhere may be lifted straight from DreamMaker, this will serve as a small "pointer" to where you can find that same functionality in StrongDMM. Everything you can do in Dream Maker, you can do about 100 times better in StrongDMM. If you've managed to grasp the bare essentials of even playing Space Station 13, then I have no doubt that getting acclimated to StrongDMM will probably be a walk-in-the-park. However, BYOND hasn't changed in how it parses maps, so that will all hold steadfast and true.

At the time of me writing this guide, StrongDMM is currently in an “alpha state” (Versions 2.0.0 and up). I will be using the alpha version since it’s the path the program is going to take in the future, but if you’re hesitant about an alpha version, feel free to downgrade to Version 1.9.1 (it has a few features 2.0.0 is missing). You can actually run both concurrently, too! Regardless, let’s start mapping!

Starting StrongDMM

Go into "File" in the top-right of your screen and hit “Open Environment”. The “environment” is how StrongDMM is able to find, collect, and parse the atoms that make up every part of every map. This is an important step, and make sure you always use the .DME (Dream Maker Environment) file on your repository to keep things as straightforward as possible. Just get tgstation.dme.

Your map in StrongDMM

Then, go back into "File" and hit "Open Map". You'll want to go into the ``_maps`` directory of your repository, and then find any map you like. I'll be using MetaStation.dmm for the purposes of this guide. Once StrongDMM loads the map of your choosing, you can use Middle-Click and the Scroll Wheel to find your way around. Soon, you should get something that looks like this:

Layers and their keybinds to toggle them

Beautiful! Let’s talk about those colors. Those are areas which are important for the game to understand what discrete location is what, and we use it for several things code-side. For example, the bridge is a different area than the bar, so you want to make sure everything is defined appropriately. They tend to be a bit distracting through, so you can hit Ctrl+1 to get rid of those. Do make sure you define them properly when you’re done, though.

Areas are one of four different, distinct “layers” we use in BYOND. The other three are turfs, objs (for Objects), and mob (for creatures/animals/what-have-you). Their progenitor species is the atom. You can go into the options tab or hit the respective keybind to quickly filter for those.

---

Editing

These are your tools to edit with. From left to right, they are: Add (1) Fill (2) Grab (3) Pick (Hold S) Delete (Hold D) Replace (Hold R) They each do their own thing, and you can hover over them in the program to see what you might want to use. Feel free to get a feel with the tools by toying around with stuff, and eventually getting to work on your own maps as you desire.

Testing Your Map

The “Open in Visual Studio Code” button. Click the image to expand.

You should always test your code, test your maps, test your sprites, test everything whenever it’s a non-trivial amount of work. There’s an incredibly simple way to do this, which I’ll reveal to you now:

The easiest/fastest way to do this is to go into Github Desktop and find the button that reads “Open in Visual Studio Code”. If it doesn’t, set your default editor to Visual Studio Code.

Once inside Visual Studio Code, you'll want to hit Ctrl+F5, or just F5. This will start compiling your code, which shouldn’t take more than a few minutes. Once done, it’ll boot up BYOND’s Dream Seeker, connect you to the local server, and automatically give you the highest permissions. This is because you’re doing everything in the debugging mode, which is quite nifty. This is arguably the simplest way to do it.

Once Space Station 13 has started, the Server tab located in the Stat-Panel will be a big help. From there, you can change maps and also skip the post-initialization wait time by clicking Start Now (or just type Start-Now in the command bar). Observe as a ghost and view your changes. Compiling is a good way to view the more subtle nuances that you weren’t able to pick up on through the editor. This includes (but is certainly not limited to): lighting, door accesses, mob interactions, and just figuring out if it looks good.

---

Simply follow these steps and you should be able to catch most errors mapping brings. The Pre-Commit Checklist, also provided in a dropdown below, best applies to outright Station Mapping and may not be applicable to ruins/away missions/shuttles/etc., but it’s still quite good to check as much as you can rather than assume that it works.

Click to expand Map Testing ChecklistClick to retract Map Testing Checklist

• Are floors with or without air, as they should be? (regular or airless)
  • You can test this one out by looking for Active Turfs.
• Does the area have an APC?
• Does the area have an Air Alarm?
• Does the area have a Request Console?
  • Not every area needs this, look at other stations.
• Does the area have lights?
  • When you compile your map for testing, make sure the lighting is adequate. You don’t want any unwarranted “dark” spots in your rooms. If you’re going for “warm” or “cold” lighting, make sure it all matches.
• Does the area have a light switch?
  • Only smaller rooms that get minimal traffic should recieve lightswitches. Areas like primary hallways should definitely not have them.
• Does the area have enough security cameras? (Use the Debug Verbs for help)
• Does the area have enough security cameras? (Use the verbs under Mapping for help)
• Does the area have enough intercoms? (The verb Intercom Range Display in the Mapping Debug Verbs helps with this.)
• Is the area connected to the vent air loop (distro)?
• Is the area connected to the scrubber air loop (waste)?
• Is everything wired properly?
• Does the area have a fire alarm and firelocks?
  • Typically, doors leading into maintenance do not need firelocks. Do not place firelocks on doors facing the exterior of the station (like space or the planet).
• Do all airlocks work properly?
• Are accesses set properly on doors, buttons, etc.?
  • For typical airlocks, you can use the Airlock Mapping Helpers. Otherwise, consult the reference for Door Accesses.

SpaceSmithers says: "I'm working on an Access Helper table which might help for this part. Also, I copied the checklist into a nifty dropdown seen above in the hackmd port."

Big Chungus says: "san7890 went through and documented all of the access helper define macros here: https://github.com/tgstation/tgstation/blob/master/code/__DEFINES/access.dm don't know how much that helps."

SpaceSmithers says: "Looks good. A much needed update, I think. Side note: Keycard Auth grants auto-connect ability on Holopads. Smithers' Niche Funfact #113."

• Are all items placed properly?
  • In summary, are your objects all on tables as needed? Are tables or other objects obscuring your vents/scrubbers?
• Does the disposal system work properly from all the disposal units in this room as well as the pipes of which pass through this room?
  • Just throw yourself through a few disposals systems that seem to pass through the area you touched. Easy to forget.
• Check for any misplaced or stacked piece of pipe.
  • /tg/station also lints for this to catch you if you forget.
• Check for any misplaced or stacked piece of wire.
  • /tg/station also lints for this to catch you if you forget.
• Identify how hard it is to break into the area and where the weak points are and balance the area accordingly.
  • For example, the Vault should be made of reinforced structures and electrified windows, the Kitchen should not. Be reasonable, not everything has to be an overly-secure structure to prevent the “tide” or other events. You will be vetted on this, just make your best choice.
• Check if the area has too much empty space.
  • You don’t want vast, bald spots in your rooms that serve little purpose. Fill it up with stuff if you can, or just trim the fat entirely. Whatever works best for the station and your design.
• Are there any indestructible turfs where they shouldn't be?

• In the Stat-Panel (mentioned previously), go into the Debug Tab. Now, select the Mapping Verbs - Enable verb.
• You should now have the Mapping Tab.
• Check for errors for cameras, power cables, and atmos pipes.
• Powersink the station and ghost around to check for unconnected powernets (APCs that aren’t discharging/charging).
• Ride disposals from start to finish to check for broken disposals.
• Make yourself an AI and check for blindspots in camera networks. You can also use the Camera Range Display Verb.
• Spawn yourself in (check Debugging Hottips)

Fix your errors, and run through this list again to double check, because chances are you missed something or you broke something else. That’s just how it is. Doing so will save everyone a lot of headaches down the line. Specifically, yours, because you will have to fix your own shit.

---

In mapping, there are a lot of errors that may come up during Initialization of the world. However, we do check for a lot of these errors. Here’s how you can check these out and get them ironed out before we have to catch it for you.

Assuming your world is already compiled, wait for Initialization to finish, and then type in this verb into your chat box Get-Current-Logs. You should see a pop-up with a whole list of logs. You just want to go down this list and select the option that says map_errors.log. Go ahead and either “View” or “Download” this log file (“Open” doesn’t typically work for me).

We also now do this check for you on every pull request for station maps through our GitHub Continuous Integration process. I would advise checking this for non-station maps, though.

Committing and Pulling

Return to GitHub and you'll see your modifications to the Map Keys in the line changes. In the bottom-left corner, you'll see the commit menu. Maintainers at /tg/ really do appreciate if you write out a thoughtful commit title and description, because you will need to justify your changes in one way or another when you submit it for review through the Pull Request Process!

Committing your changes

An example of a good commit title and message.

Once you've written the constructive title and brief description, hit "Commit to (your branch name here)”. If it says “Commit to Master/Main”, don’t hit that button because you’ll dirty the master branch of your forked repository. Make a new branch, and base it off what you’re currently on. If it doesn’t say that, everything’s just fine. Congratulations, you’ve “committed” your changes!

What if you didn’t like that, realize you made a typo, or just wanna go back? You can always just go back into StrongDMM to edit your map and make a new commit, but you can also go to the History tab, right-click on your commit, and click "Undo commit...", which will just undo your commit, and then you can make as many changes as you please, then recommit. This is one of the greatest advantages of Git, it has a powerful versioning system that you can easily use to hop from one day’s work to another.

If you’re happy, then seek out a "Publish branch" button. This will upload your branch to the remote (github.com).

Creating a Pull Request

Once all the "deltas are resolved" and what-not, a "Create Pull Request" button should appear on GitHub Desktop. Click that, and your web browser will open to GitHub. Ta-da, just fill in the template just like the descriptions in the contributing template say (including an image or two of your changes is always well appreciated), hit “Create Pull Request”, and wait for the feedback to roll through. I would advise viewing some example PRs, open up a few of them (if you haven’t already been tracking how people write Pull Requests) and try to learn well.

The /tg/ guidelines for Pull Requests can be found here. Another document with friendly advice from a coder can be found here.

---

You’ve done it! You’ve done mapping! I hope that wasn’t too painful, and the rest of this page (or the links below) will introduce you to some deeper contents that I briefly touched on in regards to mapping.

Closing Notes

While this guide is meant to contain the bare-bones of information to get people started on mapping, the Mapping Reference Collection will contain a wealth of information for mappers. I heavily recommend reading this.

Stumped? Feel free to ask some more experienced mappers any questions on the /tg/ forums or the Discord

---

SpaceSmithers' Guide to Mapping Supplementals

SpaceSmithers says: "Since almost all of Metacide's guide will be overwritten, I'll be sure to include a hyperlink at the top of the page that will take the user to an older version of the page with Dream Maker instructions. It could be useful to someone, I guess. You can always check out an earlier revision of this page to review older info from this draft."

---

SpaceSmithers says: "Double-check for missing or needed hyperlinks, and if more supporting images could be added."

The first step, then, is to be able to create your first few rooms. Select an open turf from the generic simulated floors, preferably /turf/open/iron. Each floor has a preset make-up of air on them, unless you use one titled "airless". Surround these floors with walls, and hey presto you have a room. Try sticking some tables in there, perhaps a vending machine or two.

If you want to add some chips to your new den but are unhappy with how they neatly stack on top of each other, you can adjust their "pixel_x" and "pixel_y" values with the Nudge and Dir menu. You can click & drag the values, use the mouse wheel on them, or double-click on them to enter exact values.

The Prefab and Instance menus.

Changes by Nudging or in Direction (dir) are reflected in the Prefab and Instance menus. All modified values are green so it's easier to identify them. Un-modified variables may be hidden, in which you'll need to uncheck "Show modified only" by clicking on the gear icon. Most wall-mounted machines on stations are shifted like this, and while they APPEAR to be on a wall, they are actually on the tile in front of it. Luckily, most wall mounts come with convenient directional subtypes in the object selector so you don't have to manually nudge them. Just don't go overboard with this, as every new instance of an object is added as its own entry in the menu, and when there are dozens of them it can get hard to remember which one you wanted(still relevant? I guess it clogs the prefab menu.). Once you've made your room you'll want to put lights in.

There is one uninvited guest here!

Important: While building your station you might find yourself in need of an object with a specific alignment (windows, pipes, cables etc) that does not appear in your menu. This is because BYOND does not simulate instances of an object other than its base state unless they are present on the map. You can generate them by right clicking an object and selecting "generate instance from state/direction". This function has an unwanted feature in which a generated object sometimes has a tag added automatically. These tags can cause error with certain features of the game during a round, and need to be removed. To check for it, right click an item on the map or in the menu, select "edit" and scroll to the "tag" line, which should be empty save for two doublequotes (""). If it's not (which is easy to tell since the tag is massive and bold, impossible to miss even scrolling at lightspeed), change it. Well maintained maps don't usually contain these, so you should be safe to copy-paste to your heart's content. As a tip, remember that all non-standard objects have their own entry in the menu, and having a tag is not standard at all for most object!   SpaceSmithers says: "At San's request, the Prefab section will be re-written to better suit modern expectations and definitions, and to account for SDMM."

So now we get to the basics of making a functioning room. First of all, you'll need to re-enable the area layer. Pick some area from the object tree, and cover your room in it. You can rename this area if you want (Really? We can manually edit the names of areas?), we'll do that later. Make sure the area isn't used anywhere else on the map. Each area should have one APC (Area Power Controller) in it. When creating an APC, the "auto_name" subtype will automatically name the APC to the area that it is in. Or, you can use the generic parent type and manually set its name variable. Other subtypes of APCs may include "unlocked" and "highcap". For testing, you might want to use a "highcap" variant that stores more energy, since we don't have a power source yet. Alternatively, you can change the "cell_type" variable to /obj/item/stock_parts/cell/infinite for infinite power (Source: It came to me in a dream. Untested.). If there are no directional types for the APC you're using, you can use the Nudge and Dir menu from earlier to adjust it. In a normal power system, you'd connect the APC up to all the others and the station's generator via SMES cells, but we'll do that later. For now you have a basic room that is powered and starts with enough air to breathe happily. You can put an air canister in if you think you'll consume all the oxygen, or somesuch.

Important Note: There are nudge_x and nudge_y variables in the editor, as well as various z-axis variables. Don't ever change these, they're not used in SS13 and break things.(Needs to be re-written for SDMM's nudge menu.)

To be able to actually spawn into a room, you'll want to place spawners. You'll see these as the big red X symbols on the default map, for each role. There are also blue Xs for xeno spawn locations (pretty sure spawners now use fancy sprites for their respective spawns) and the spawns for all latecomers on the arrival shuttle.(old/irrelevant, shuttles are not placed onto station maps anymore.) Stick in a spawn_late somewhere in your room for now.

(may change for redundancy reasons) To actually test your map and be able to screw around in it as an admin, you'll have to compile it. The easiest way to do this is through Github Desktop, where you will open the repository in your external editor by clicking the "Open in Visual Studio Code" button. If this is not present, change your default editor in the options to Visual Studio Code. In Visual Studio Code, press F5 to both compile and launch the game. Full permissions are automatically granted as "localhost".

The best possible training is through experience. From here on out, you can make whatever you like, really. Copying the default map and working out how everything works isn't too hard and is fairly rewarding. You could just tweak the default one if you like. The first thing I made was a small shuttle - you can see this at the bottom. Just tweak and add stuff and you'll work out how almost everything works fairly easily. Poke around with both Github Desktop and StrongDMM. For explanations of wiring, piping, and atmos, ask away on the mapping channel of our discord or on the forums.

Gas tanks and filters

SpaceSmithers says: "This section will be overhauled. It may not be exhaustive, however. It will probably just describe key points such as monitored meters, mixing, common errors, etc. Similar to how it is currently."

Each station should have a full set of these - or at the bare minimum, one for N2, one for O2 and a third tank to filter dangerous gases into.

Left to right: N2, O2, Airmix. The canisters inside are just for decoration.

Each gas tank needs:

• Outside: A tank computer and a gas filter to pick what gases will be filtered into it.
• Inside: A gas injector (input), a vent pump (output), a gas sensor and a specific turf.

The tank computer controls the input/output and receives data from the gas sensor.

The specific turf creates the gases that will be inside each tank - the gas canister is just for decoration.

Let's take a look at the MetaStation N2 tank:

• Tank computer: /obj/machinery/computer/atmos_control/tank/nitrogen_tank
• N2 filter: /obj/machinery/atmospherics/components/trinary/filter/atmos/n2
• Gas injector: /obj/machinery/atmospherics/components/unary/outlet_injector/atmos/nitrogen_input
• Vent pump: /obj/machinery/atmospherics/components/unary/vent_pump/siphon/atmos/nitrogen_output
• Gas sensor: /obj/machinery/air_sensor/atmos/nitrogen_tank
• Turf: /turf/open/floor/engine/n2

These objects have all the neccessary vars preset and start switched on - you'll only have to edit the dir if neccessary.

Additionally, you'll want this type of gas mixer for the airmix tank (N2 + O2):

• Air mixer: /obj/machinery/atmospherics/components/trinary/mixer/airmix

Shuttles

SpaceSmithers says: "IMPORTANT: I don't want a repeat of the old guide; this is not the place to dump random shuttle code documentation. This is a mapping guide. Keep things simple and clear for mappers. If you want to document shuttle code, comment in the code itself or make a separate, dedicated wiki page."

There are two types of shuttle docks:

• stationary == places where the shuttle can dock
• mobile == placed on shuttles

Mobile ports will dock directly on top of stationary ports.

Sometimes listed as its own type of port, transit ports /obj/docking_port/stationary/transit are automatically generated in a dedicated transit z-level, so you don't have to worry about that.

Stationary Ports

For places like arrivals and departures, we will have to add a /obj/docking_port/stationary for each, and manually edit in some variables for them to work. It's a good idea to have an updated, pre-existing map open in your workspace to reference or copy.

Before we do anything, lets identify some of the variables we will likely be seeing.

• dir: The direction of the port.
  • If a shuttle's mobile docking port direction is different than the stationary docking port's direction, the shuttle and all items on it will be rotated accordingly.
  • This rotates the entire plane. Other variables, like width and height, are relative to this direction. This means that on a docking port facing west or east (dir = 4 or 8 respectively), height will be horizontal on the mapping workspace, and width will be vertical.
• height: The size of covered area, parallel to dir.
• width: The size of covered area, perpendicular to dir.
• dheight: Distance in height from the (0,0) origin point to the dock. More details can be found here.
• dwidth: Distance in width from the (0,0) origin point to the dock. More details can be found here.
• name: A name string for the port. This name will be visible on shuttle consoles, Shuttle-Manipulator admin verb, and during debugging.
• roundstart_template: The template that will spawn on this port when the map initializes. Used on docks for arrivals, escape pods, and more.
• shuttle_id (formerly id): Identification variable. Mandatory for certain ports.
  • IMPORTANT: For standard stations, you MUST use these exact strings for the listed areas, or else they will not function. Stub? double-check all instances of shuttle_id in case i missed some.
    • Arrivals dock: "arrival_stationary"
    • On-station dock for centcom ferry: "ferry_home"
    • Emergency Shuttle Dock: "emergency_home"
    • Cargo Dock: "cargo_home"
    • On-station Whiteship dock: "whiteship_home"
    • Auxiliary Base Construction: "aux_base_zone"

A stationary port is strict with its width and height variables when deciding if a shuttle can dock there. They should generally be greater than or equal to the dimensions of the shuttle that wants to dock. If a shuttle is larger than the stationary port's dimensions, it will outright refuse to dock. When testing your map, debug/admin tools such as the Shuttle-Manipulator verb will be a tremendous asset.

The stationary ports for the labor shuttle, mining shuttle, public mining shuttle, and the auxiliary base zone each have their own, unique subtypes. These are presets and should not be edited, except for their direction.

Escape pods utilize two unique stationary port types for each pod; one is the escape_pod subtype to spawn the pod itself (which should go unedited except for its direction), and also the random subtype. When the map initializes, the random ports are automatically teleported to a random spot in lavaland (or the icemoon if using the respective icemoon subtype). These spots are reserved for emergency launches when the station is on red or delta alert levels. Random ports need a shuttle_id for pods to dock, and generally use the following naming scheme: "pod_lavaland", "pod_2_lavaland", "pod_3_lavaland", and so on.

Most stationary ports generally face the shuttle or face away from the thing the shuttle docks with, but not always, as it depends on the position of the mobile port on the shuttle. If you're unsure where to place the docks, its always a good idea to use another pre-existing map as a reference. Also remember that mobile ports park directly on top of stationary ports, and will also rotate to adopt their dir.

Mobile Ports

The mobile port variables are quite different from their stationary counterpart. Lets go through them:

• The width, height, dwidth, and dheight are all generated automatically.
  • Many existing shuttles in the codebase do have these variables edited in despite not being required.
• name: Name your spacecraft! Will be printed in consoles and also station-wide announcements if its an escape shuttle.
• preferred_direction: The direction the shuttle appears to travel in. Changes the parallax animation.
• port_direction: Relative direction of the docking port from the front of the shuttle. If you rotate the ship so that it points north, what direction will the mobile port be facing?

You should cover your entire shuttle with one or more proper subtypes of /area/shuttle, especially if its an escape shuttle with a brig on it. This ensures that everything works and moves properly. Otherwise, your shuttle may encounter unwanted errors or claim turfs within the bounding box that shouldn't be moving with your shuttle.

Some shuttles should be using specialized subtypes of the mobile docking port, like arrivals and emergency shuttles. Be sure to check these subtypes before settling with the generic one, or else they may not work as expected.

Dwidth and Dheight

This section can get a bit confusing at first, but it will get better as it goes along. The area of the docking port is not centered at the dock itself; at first, the dock will be at the (0,0) coordinate of the area, which we will label as the origin point. Its important to note that the entire grid, along with the origin point, will rotate with the docking port's direction (dir), just like other variables.

Port Dir	Origin point (0,0) location
1 (North)	Bottom-left
2 (South)	Top-right
4 (East)	Top-left
8 (West)	Bottom-right

SpaceSmithers says: "This table (that I, myself, made) might be misplaced or outright unnecessary. I'll come back to decide its fate at another time."

dwidth and dheight define the relative position of the docking port in its own covered area by measuring from the origin point (0,0). Since we're calculating the distance from the origin point, a (0,0) coordinate, the tile with origin point itself does not count for these measurements.

To the average mapper, all of this technical jargon is incomprehensible. We'll use some visual diagrams to help explain what it all means.

Docking port reference guide. Click to expand.

Displayed is an example port facing in four different directions. We can see how everything rotates as the port's dir changes, such as width and height, its delta counterparts, and the tile marking the (0,0) origin point. Lets look at dwidth and dheight and note how it measures from the origin point (0,0) to the docking port, and how the tile with the origin point is not counted. Measuring these tiles for this example port, we see that dwidth is 3 and dheight is 4. If there's anything you should pick up from this section, reference this image to determine where and how you should be measuring.

Metastation's Arrival Dock.

Lets apply this knowledge. Here in this image we have Metastation's arrivals dock. You can see the area it covers with its width and height variables. Since the port is rotated to the west, width, height, and the origin point (0,0) are all rotated as well. In the image, you can see how dwidth is measured from the (0,0) tile. The dheight variable goes unedited in this case, because the dock is 0 tiles away height-wise from the (0,0) point, and the default value is already 0.

Setting the offset for where the docking port is relative to the covered area is important for making sure shuttles can fit within the respective bounds. Without dwidth and dheight, the dock would always be stuck in the corner at the origin point, and certain shuttles would fail to dock properly. This is especially true for docks that support interchangeable shuttles that differ in size, like departures.

JSON/Map Configuration

SpaceSmithers says: "Work in-progress. Documented from maps.dm, map_config.dm, and more. Certain entries could use examples or more depth."

Your map should come with a JSON configuration file placed in the "_maps" folder, especially if its utilizes Multi-Z. This config file points the game to where your map is located, the map's name, what shuttles will be used, and more. All listings will be case-sensitive. Lets go through some of the more common configuration types.

• version: Version tracking was introduced in pull #53663, but goes unused in the /tg/ codebase. Set this to "1" like every other map.
• map_name: The official name for your map. Will be referenced in the stat-panel or external hooks like the Discord bots.
• map_path: The folder where the map .dmm file is located. The "_maps" folder will be the root, so this string should look something like "map_files/YourStation",.
• map_file: The filename for your map that is found in the above folder. Example: YourStation.dmm.
• shuttles: This entry will be a list. These are the shuttles available for changing:
  • cargo: The cargo shuttle.
  • ferry: The ferry generally used by admins that travels between Central Command and the main station during the round.
  • whiteship: The whiteship that will spawn in space somewhere for those explorers.
  • emergency: The Escape Shuttle. Remember that this is interchangeable during the round via communications consoles, unless allow_custom_shuttles is set to false.
• planetary: If the map is planetary, set this to "1".
• space_ruin_levels: Planetary maps should include this and have it set to "0"
• space_empty_levels: Planetary maps should include this and have it set to "0"
• job_changes: This will expand into a list consisting of job titles, which will list again into changes for that job. Some jobs like Captain and Cook have unique modifiers exclusive only to them.
  • Captain
    • special_charter: Adding this variable will replace the charter with a banner representing the claim to a celestial body. IceboxStation has this set to "moon", while Kilostation and Tramstation have this set to "asteroid".
  • Cook
    • additional_cqc_areas: Extra areas for the Cook's close quarters combat abilities. An example entry would be ["/area/station/service/bar", "/area/station/commons/lounge"], extending the range to both the Bar and the general Lounge areas.
  • The following modifiers can be used for any job, such as Station Engineer or Prisoner.
    • spawn_positions: Sets the amount of positions that can be filled at roundstart.
    • total_positions: Sets the total amount of positions available after roundstart. Roundstart positions will still be filled to the number defined in spawn_positions, even if this variable is set to a lower number. If both of these variables are set to zero, the respective job will not be listed in either preferences or the late-join menus.
    • additional_access: Grants extra access to the respective job. Grant the Clown armory access. See jobs.dm for help with access.
    • additional_minimal_access: Grants extra access to the respective job when the station is under-staffed. IMPORTANT: These are two separate lists and do not stack. This means that during a skeleton crew, only the accesses listed here will be granted, and those under the regular additional_access will not carry over.

Z-Traits

TEST: Setting traits in .json will not retain default Z-level linkage? See this PR fixing Kilostation's space exploration by manually re-adding z linkage. Defines listed under trait are for configuring the map's Z levels. For example, designating where levels of a Multi-Z map are relative to the others, enabling weather, mining, ruins, and more.
Important: If you are adding/modifying any z-trait to a config file, you must include Linkage because the default is not retained, resulting in an 'invisible wall' effect to the map's edges.

• trait:
  • "Linkage": Defines how z-levels are traversed at a map's edge. Stations in space use "Cross", while planetary stations are set to "null". When nulled, hitting a map's edge does nothing.
  • "Secret": Boolean. Does this z-level prevent ghosts from observing it?
  • "No Phase": Boolean. Forbids teleporting and such. True for the CentCom level.
  • "No X-Ray": Boolean. Forbids xray, meson, thermal vision.
  • "Bombcap Multiplier": Number. Multiplier for the bombcap. KiloStation, a lower-pop map, has this set to 0.7.
  • "allow_custom_shuttles": Boolean. If set to false, the Purchase Shuttle button on communications consoles will be removed.

---

Multi-Z: turf definitions and z-level and traits are required for Multi-Z maps.

good reference for up & down vars in multi-z config

SpaceSmithers says: "I'll add a section showcasing one or more full config JSON files to demonstrate proper formatting, with comments explaining their functions."

Multi-Z

SpaceSmithers says: "Untouched section. It may become overwritten or obsolete."

Multi-Z is a feature which allows a station map to have multiple Z-levels layered on top of each other, behaving as a single station with multiple floors. This feature is currently in use on the Tramstation and IceboxStation maps. A station's multiple levels can be bundled into one map file, or in several seperate files. The traits section of the map configuration json tells SS13 how to link the maps together.

• If you are building station rooms on a lower Z level, ensure that a turf of some type is mapped on the Z-Level above the room to function as a “ceiling”. You can check the coordinates in the Mapping Editor to ensure you map over the correct dimensions of the room. When running the server to test the map, you can go to the Debug tab and hit “Mapping Verbs - Enable”, go to Mapping tab and hit Show ATs. If the list is empty, you are good.
• Earlier versions of Multi-Z did not require a baseturf to be defined under each Z-Level’s traits in the config JSON. Each level must now have a baseturf set.
• The maploader will not load and link a map file without areas or turfs defined. An empty space (nothing but baseturf) map will runtime. If you are adding a Z-level to an existing map, be aware of this.
• SS13 will cache a map’s configuration JSON file in data\next_map.json. If you alter a map’s configuration JSON locally, you must also clear this file by using the change-map verb in game, deleting the file, or replacing it with your updated JSON file