CM-SS13 - Wiki - User contributions [en-gb]

Template:Main page/search

2026-01-28T05:59:17Z

Drulikar: search button fix?

<div class="home-header">
<div id="citizen-search-trigger" class="home-header__search citizen-search-trigger" role="button"><span class="home-header__searchIcon">[[File:WikimediaUI-Search.svg|16px|link=]]</span><span class="home-header__searchText">Click here<span class="desktoponly"> or press {{Key press|/}}</span> to start searching</span></div>
</div><templatestyles src="Template:Main page/search/styles.css"/><noinclude><templatestyles src="Template:Main Page/Shared/Styles.css" />{{/doc}}</noinclude>

MediaWiki:Sidebar

2025-12-27T03:54:20Z

Drulikar: Add PvE WIki links to sidebar

* Main
** https://github.com/cmss13-devs/cmss13 | GitHub
** https://forum.cm-ss13.com | Forum
** https://www.cm-ss13.com/rules | Rules
** https://cm-ss13.com/wiki/PVE:Main_Page | PvE Wiki
** https://cm-ss13.com/wiki/HCW:Main_Page | PvE Halo Wiki

* Marines
** https://cm-ss13.com/wiki/Marine_Quickstart_Guide | Quickstart Guide
** https://cm-ss13.com/wiki/Marines | About the Marines
** https://cm-ss13.com/wiki/Marine_Equipment | Marine Equipment
** https://cm-ss13.com/wiki/Requisitions | Requisitions
** https://cm-ss13.com/wiki/Standard_Operating_Procedure | Standard Operating Procedure
** https://cm-ss13.com/wiki/Marine_Law | Marine Law
** https://cm-ss13.com/wiki/Rank | Rank

* Aliens
** https://cm-ss13.com/wiki/Xeno_Quickstart_Guide | Quickstart Guide
** https://cm-ss13.com/wiki/Aliens | About the Aliens
** https://cm-ss13.com/wiki/Hives | Hives
** https://cm-ss13.com/wiki/File:Evolution.png | Evolution Diagram
** https://cm-ss13.com/wiki/Strains | Strains

* Maps
** https://webmap.affectedarc07.co.uk/ | Webmaps
** https://cm-ss13.com/wiki/USS_Almayer | USS Almayer
** https://cm-ss13.com/w/images/6/6f/LV624.png | LV-624
** https://cm-ss13.com/w/images/1/18/Map_icecolony.png | Shivas Snowball
** https://cm-ss13.com/w/images/7/78/Whiskey_outpost.png | Whiskey Outpost
** https://cm-ss13.com/w/images/9/9e/Solaris_Ridge.png | Solaris Ridge
** https://cm-ss13.com/w/images/4/4c/Map_Prison.png | Fiorina - Cellblocks
** https://cm-ss13.com/w/images/e/e0/Prison_Station_Science_Annex.png | Fiorina - Science Annex
** https://cm-ss13.com/w/images/9/92/Trijent_Dam.png | Trijent Dam
** https://cm-ss13.com/w/images/8/8e/CORSAT_Satellite.png | Corsat
** https://cm-ss13.com/w/images/2/21/Sorokyne_Wiki_Map.jpg | Sorokyne
** https://cm-ss13.com/w/images/0/0d/Kutjevo_a1.jpg | Kutjevo
** https://cm-ss13.com/w/images/b/bb/C_claim.png | Chance's Claim
** https://cm-ss13.com/w/images/9/94/New_Varadero.png | New Varadero
** https://cm-ss13.com/w/images/6/60/LV759_Hybrisa_Prospera.png | LV-759 Hybrisa Prospera

* Lore
** https://cm-ss13.com/wiki/Lore_Home | Lore
* Wiki Editing
** https://cm-ss13.com/wiki/Special:RecentChanges | Recent Changes
** https://cm-ss13.com/wiki/Special:ActiveUsers | Active Users
** https://cm-ss13.com/wiki/Helping_Out | How to Wiki
* SEARCH
* TOOLBOX

Researcher

2025-12-25T06:15:14Z

Drulikar: Added research tagged guides to User made information section

{{JobPageHeader
|headerbgcolor = #2175d9
|headerfontcolor = white
|stafftype = MEDICAL / RESEARCH
|imagebgcolor = lightblue
|img = Sci.png
|jobtitle = Researcher
|difficulty = Medium
|rank = Doctor [under 10hrs], Assistant Professor [10hrs], Associate Professor [25hrs], Professor [70hrs], Regents Professor [175hrs]
|superior = [[Chief Medical Officer]], [[Commanding Officer]]/[[Executive Officer]]
|unlock = Five hours as medical roles.
|duties = Research and Development, inspect any xenobiological elements given to you by Marines. Develop new weaponry such as Chemical Grenades in cooperation with the Ordnance Technicians and discover new chemicals.
|guides = [[Chemistry | Guide to Chemistry]], [[Guide_to_Paperwork | Guide to Paperwork]]
|description = You're a medical researcher on loan to the USCM from Weyland-Yutani. You are tasked with researching and developing new medical treatments, helping your fellow doctors, and generally learning new things. Your role involves a lot of roleplaying, but you can perform the function of a regular doctor. Do not hand out things to Marines without getting permission from your supervisor. You do not answer to the Corporate Liaison.
}}
{{Header
|PrimaryColor = #ad8407
|SecondaryColor = #ffffff00
|HeaderContent = <span style="color:black">Work in Progress</span>
|Image = Under_Construction.png
|SubContent = Due to recent changes from the Research Rework, content on this page may be missing important information or be incorrect. This page has been designated as a work in progress. To locate any other work in progress pages head [[:Category:WiP | here]]
|Category1 = WiP
}}
''"I wish you could understand what we're trying to do here. The potential for this species goes way beyond urban pacification. New alloys, new vaccines. Nothing like this we've ever seen on any world before."'' ―Dr. Wren, ''Alien Resurrection''

== Role ==
----
As the Medical Researcher it is your job to research and develop new technologies in the science lab and study anything xenobiological. The nature of the Researcher means the role is very open-ended, and can be played in several ways.

Ultimately, your job is to focused around analyzing chemicals, alien blood/liquids, storing alien corpses. Synthesizing experimental drugs and creating prototype explosive grenades. Furthermore you are fully qualified to assist the Medical staff with surgeries, should Medbay be overwhelmed in triage.

=Chemical Research: Pharmacology=
Research has its own chemistry lab that can be used to help out medical by pumping out useful healing chemicals. It is also possible to mix chemicals together to get multiple benefits; however, be aware that there are certain chemicals which will cause '''more harm''' if they are used together. Consult the [[Chemistry|chemistry guide]] for more details.

==Researching Chemicals==
As a medical researcher on-board the USS Almayer you're tasked with creating new medications that might be useful to the marines. But what can you do that the silly doctor in chemistry downstairs can not? Discovering completely new medications of course! Every round there will be new chemicals for you to discover. You'll even start with a note in your old lab coat pocket to get you started. Researching a new chemical requires two important tasks to be completed: discovering the recipe and the properties of the chemical. The latter requiring either thorough testing or sufficient data clearance. So what are you waiting for? It is time to do SCIENCE!

A lot of your work will require a resource called '''Research Credits'''. These can currently be earned by identifying new chemicals, including xenomorph blood, or by gaining 5 points every 10 minutes.

The Company has provided your laboratory with an ''Advanced X-Ray Fluorescence Scanner'' to help you identify chemicals. On your journey, you will be expected to use this and analyze research samples received from colonies. If you identify a valuable chemical, The Company's interest in your lab will increase. They might even pay USCM High Command.

===Research Machines===
{| class="wikitable"
! style="background-color:#A9A9A9; width:130px;"|Picture
! style="background-color:#A9A9A9; width:150px;"|Name
! style="background-color:#A9A9A9;"|Explanation
|-
|[[File:XRF.png|64px]]|| Advanced X-Ray Fluorescence Scanner || The A-XRF is an advanced spectrometer that can not only detect what a sample is, but also its chemical composition. It does this by nuking the sample with high energy radiation and detecting the emitted fluorescent x-ray patterns. By comparing this to the database it can identify the unique pattern of a sampled chemical, and the combination of chemicals that make the pattern possible. Although there might be chemicals which composition can't be fully identified. This means that you must acquire a sample of the unknown chemical first, and scan it with the XRF. Whenever the XRF scans something unknown, it will save that chemical's emission pattern to its database. '''Successfully identifying a chemical increases Company interests."

Samples are inserted using a vial filled with a pure chemical sample. After scanning, the XRF searches its database for any available information on the identified chemical. It is not actually able to figure out the properties of the chemical, that will require testing.

While the A-XRF can read data from the Company's private chemical database, your clearance level is limited and some information may be classified. Use the '''Research Data Terminal''' to purchase higher clearance or get a clearance grant by a corporate official.
|-
|[[File:Chemical_Centrifuge.png|64px]]|| Chemical Centrifuge || The centrifuge is a research machine meant to assist working with the A-XRF and vial management. By using centrifugal forces it can separate chemicals from a beaker into a set of vials. To operate, insert any beaker with a mixture of chemicals and a vial box containing any amount of vials. The centrifuge will try to fill the vials with different chemicals from the beaker best possible. It will also label pure vials for you.

Additionally the centrifuge also accepts autoinjectors. To do this, load empty autoinjectors into a vial storage box and insert the box into the centrifuge. The centrifuge will recharge the autoinjectors.

The centrifuge operates under the following logic:
* Cycles through reagents in the input beaker starting from the top.
* Will fill pure vials containing the same reagent or an empty one. Purity of vials is first priority for the purpose of operating the A-XRF.
* Will ''not'' fill multiple vials with the same reagent. '''Unless the beaker only has a ''single'' reagent, then it will try to fill all as much as possible. This is useful for when filling autoinjectors.'''
* Will ''not'' transfer reagents from the input beaker if it is within an impure vial inside the box. Use this feature to make impure vials act as filters.
|-
|[[File:Turingdispenser.png|64px]]|| Turing Dispenser || This advanced dispenser is only available to researchers and allows for a level of automation in chem production. While it is relatively complicated to use, it can become a powerful tool in the right hands. Use it to automate the production of advanced research chemicals or complicated drug mixes.

The Turing Dispenser operates by following a set of instructions for what it should be dispensing. These instructions are provided by inserting a vial box, with the vial containing the amount of the chemical you want to dispense. The dispenser reads the vials in order from left to right. The dispenser will run until either: the output beaker is full, all program cycles has finished or a setting is changed while running.

Unlike the normal dispenser, the Turing Dispenser can directly dispense a wider range of chemicals. It can dispense any chemical the normal dispenser can with the exception of ethanol. In addition to any chemical available from the medical vendor with the exception of oxycodone. It can also directly dispense simple chemical compositions such as Sodium Chloride, Methane and Ammonia. Any other chemical requires the use of the ''Smartlink'' to be dispensed.

'''Programs'''
The Turing Dispenser has two programs: ''Box'' and ''Memory''. ''The Box Program'' is the currently inserted vial box, while ''The Memory Program'' is a Box Program that has been saved to the dispenser’s internal memory. The dispenser can run with just one of either program, or with both; in which case the Memory is run before the Box. This allows up to 12 dispensing steps to be configured (as each box can hold 6 vials).

'''Settings'''
* Program Multiplier: Multiplies the amount of the reagent that’s dispensed on each step. For example, a step with 20 water and a 3x multiplier will dispense 60 units of water.
* Program Cycles: How many times the full cycle of programs will be run before the dispenser goes to sleep.
* Autorun: If ON, then the dispenser will run the program automatically when both a vial box and a beaker is inserted.
* Smartlink: If ON, then the dispenser will check the nearby ''Smartfridge'' for the required chemicals before spending energy to dispense it. Additionally, this allows the dispenser to dispense ''exotic'' chemicals stored in the Smartfridge, making any recipe possible. If the required chemical can not be found and can not be dispensed using energy, then the dispenser will pause the program until the chemical is stored in the Smartfridge. Once available, the program will continue automatically. ''(Beware that, the dispenser will read the Smartfridge from top to bottom and use any beaker or bottle it finds containing the required chemical, even if that container is contaminated. This theoretically allows for more than 12 different chemicals to be dispensed in a cycle.)''
|-
|[[File:Researchterminal.png|64px]]|| Research Data Terminal || This terminal found inside the research study allows control of all research assets. It contains the database for all saved research documents, such as A-XRF scans and Synthesis reports. You can read the documents directly from the terminal, or print a copy. Additionally, the current status of research credits can be checked, and used for various functions. Any document can be added to the database by clicking it with a paper in hand.

'''Purchase Clearance'''
Upgrades the current clearance access by one level. Increasing the clearance level this way costs more the higher your clearance. Colony CLs can increase clearance for free, Up to a certain level. It also gives you one free research chemical each time you buy clearance to help you with your studies.



'''Publish'''
The CMO's data terminal has the special function of publishing documents. This allows anyone with a HealthMate HUD to view the document remotely. Any paper scanned in the research terminal can be published in this way, even handwritten ones. It is thus a useful method for the CMO to provide precise information to medics on new chemicals that are being distributed in the field, or any other useful documentation. Be sure to ask your CMO to publish your hard work, and for him to announce over medical comms that a new paper has been published.
|-
|[[File:SynthesisSimulator.png|128px]]|| Synthesis Simulator || This computer uses advanced algorithms to perform simulations of reagent properties, for the purpose of calculating the synthesis required to make a new variant. It needs a complete data sheet from an A-XRF scan to function, meaning that all components and properties of the chemical must be known. All simulations requires research credits. Any time you modify a chemical property of a reagent, Its OD threshold will decrease. ''Mixing a chemical with another variant of itself will cause it to react back into its original form.''

'''Amplify'''
This function increases the level of the selected property by one. The credit cost increases based on the level of the property.

'''Suppress'''
This function is the opposite of Amplify, meaning the level of the property is decreased. The credit cost for this function is always 2.

'''Relate'''
The relate function makes it possible to change the actual properties of the chemical. To do this, an A-XRF analysis of a reference chemical must also be inserted. The target and reference property must be of the exact same level for relation to be possible, and the target must have more than one property. The credit cost is equal to the level of the targeted property.

==== '''Chemical Naming Conventions''' ====
When a chemical property is changed, the simulator will automatically label the chemical with a code telling you about the changes. The codes are three letter combinations followed by a number signifying the new level of the property.
|-
|}

==Properties==
This is a list of all chemical properties and their effects. They are sorted in the same categories as in the code. <POTENCY> is half the level of the property.

The DISABLED rarity means this property can't appear in randomly generated chems. The same goes for ADMIN, with the addition that very few non event exclusive reagents have properties with this rarity level.

All effects are applied once per life tick. Life ticks happen once every two seconds.

The Touch column indicates what this chemical will do when inhaled/sprayed upon a human or xenomorph.



===Positive===
{| class="wikitable sortable" style="width: 100%;"
! style="width: 5%; margin: auto; background-color: #A9A9A92A;" |Code
! style="width: 10%; margin: auto; background-color: #A9A9A92A;" |Name
! style="width: 10%; margin: auto; background-color: #A9A9A92A;" |Rarity
! class="unsortable" style="width: 20%; margin: auto; background-color: #A9A9A92A;" |Effect
! class="unsortable" style="width: 20%; margin: auto; background-color: #A9A9A92A;" |OD
! class="unsortable" style="width: 20%; margin: auto; background-color: #A9A9A92A;" |Crit OD
! class="unsortable" style="width: 15%; margin: auto; background-color: #A9A9A92A;" |Touch
{{:Properties/Antitoxic}}
{{:Properties/Anticorrosive}}
{{:Properties/Neogenetic}}
{{:Properties/Repairing}}
{{:Properties/Hemogenic}}
{{:Properties/Neutralizing}}
{{:Properties/Disrupting}}
{{:Properties/Nervestimulating}}
{{:Properties/Musclestimulating}}
{{:Properties/Painkilling}}
{{:Properties/Hematopeutic}}
{{:Properties/Nephropeutic}}
{{:Properties/Pneumopeutic}}
{{:Properties/Oculopeutic}}
{{:Properties/Cardiopeutic}}
{{:Properties/Neuropeutic}}
{{:Properties/Bonemending}}
{{:Properties/Fluxing}}
{{:Properties/Neurocrygenic}}
{{:Properties/Crystallization}}
{{:Properties/Photosensitive}}
{{:Properties/Antiparasitic}}
{{:Properties/Organstabilizing}}
{{:Properties/Electrogenetic}}
{{:Properties/Defibrillating}}
{{:Properties/Hyperdensificating}}
{{:Properties/Neuroshielding}}
{{:Properties/Antiaddictive}}
{{:Properties/Transformative}}
{{:Properties/Fueling}}
{{:Properties/Oxidizing}}
{{:Properties/Flowing}}
{{:Properties/Explosive}}
{{:Properties/Cardiostabilizing}}
{{:Properties/Aiding}}
{{:Properties/Oxygenating}}
{{:Properties/Anticarcinogenic}}
|}

===Neutral===
{| class="wikitable sortable" style="width: 100%;"
! style="width: 5%; margin: auto; background-color: #A9A9A92A;" |Code
! style="width: 10%; margin: auto; background-color: #A9A9A92A;" |Name
! style="width: 10%; margin: auto; background-color: #A9A9A92A;" |Rarity
! class="unsortable" style="width: 20%; margin: auto; background-color: #A9A9A92A;" |Effect
! class="unsortable" style="width: 20%; margin: auto; background-color: #A9A9A92A;" |OD
! class="unsortable" style="width: 20%; margin: auto; background-color: #A9A9A92A;" |Crit OD
{{:Properties/Cryometabolizing}}
{{:Properties/Thanatometabolizing}}
{{:Properties/Excreting}}
{{:Properties/Nutritious}}
{{:Properties/Ketogenic}}
{{:Properties/Neuroinhibiting}}
{{:Properties/Alcoholic}}
{{:Properties/Hallucinogenic}}
{{:Properties/Antispasmodic}}
{{:Properties/Hyperthermic}}
{{:Properties/Hypothermic}}
{{:Properties/Atrichogenic}}
{{:Properties/Trichogenic}}
{{:Properties/Allergenic}}
{{:Properties/Euphoric}}
{{:Properties/Emetic}}
{{:Properties/Psychostimulating}}
{{:Properties/Antihallucinogenic}}
{{:Properties/Hypometabolic}}
{{:Properties/Hypnotic}}
{{:Properties/Hyperthrottling}}
{{:Properties/Viscous}}
{{:Properties/Thermostabilizing}}
{{:Properties/Focusing}}
{{:Properties/Unknown}}
|}

===Negative===
{| class="wikitable sortable" style="width: 100%;"
! style="width: 5%; margin: auto; background-color: #A9A9A92A;" |Code
! style="width: 10%; margin: auto; background-color: #A9A9A92A;" |Name
! style="width: 10%; margin: auto; background-color: #A9A9A92A;" |Rarity
! class="unsortable" style="width: 20%; margin: auto; background-color: #A9A9A92A;" |Effect
! class="unsortable" style="width: 20%; margin: auto; background-color: #A9A9A92A;" |OD
! class="unsortable" style="width: 20%; margin: auto; background-color: #A9A9A92A;" |Crit OD
! class="unsortable" style="width: 15%; margin: auto; background-color: #A9A9A92A;" |Touch
{{:Properties/Hypoxemic}}
{{:Properties/Toxic}}
{{:Properties/Corrosive}}
{{:Properties/Biocidic}}
{{:Properties/Intravenous}}
{{:Properties/Neuropathic}}
{{:Properties/Hemolytic}}
{{:Properties/Hemmorrhaging}}
{{:Properties/Carcinogenic}}
{{:Properties/Hepatotoxic}}
{{:Properties/Nephrotoxic}}
{{:Properties/Pneumotoxic}}
{{:Properties/Oculotoxic}}
{{:Properties/Cardiotoxic}}
{{:Properties/Neurotoxic}}
{{:Properties/Hypermetabolic}}
{{:Properties/Addictive}}
{{:Properties/Hemositic}}
|}

===Special===
{| class="wikitable unsortable" style="width: 100%;"
! style="width: 5%; margin: auto; background-color: #A9A9A92A;" |Code
! style="width: 10%; margin: auto; background-color: #A9A9A92A;" |Name
! style="width: 10%; margin: auto; background-color: #A9A9A92A;" |Rarity
! style="width: 20%; margin: auto; background-color: #A9A9A92A;" |Effect
! style="width: 20%; margin: auto; background-color: #A9A9A92A;" |OD
! style="width: 20%; margin: auto; background-color: #A9A9A92A;" |Crit OD
! style="width: 15%; margin: auto; background-color: #A9A9A92A;" |Touch
{{:Properties/Boosting}}
{{:Properties/Regulating}}
{{:Properties/Hypergenetic}}
{{:Properties/Fire penetrating}}
{{:Properties/DNA disintegrating}}
{{:Properties/Ciphering}}
{{:Properties/Crossmetabolizing}}
{{:Properties/Embryonic}}
{{:Properties/Ravening}}
{{:Properties/Curing}}
{{:Properties/Omnipotent}}
{{:Properties/Radius}}
{{:Properties/Intensity}}
{{:Properties/Duration}}
|}

===Property Combinations===
You can combine some properties to create special properties. You don't actually need to do anything to combine them. Just have them both on the same chemical.
{| class="wikitable unsortable" style="width: 100%;"
! style="width: 10%; margin: auto;" |Name
! style="width: 25%; margin: auto;" |Properties Required
|-
|[[Researcher#DFB|Defibrilating]]
|[[Researcher#MST|Muscle Stimulating]], [[Researcher#CDP|Cardiopeutic]]
|-
|[[Researcher#TMB|Thanatometabolizing]]
|[[Researcher#HPX|Hypoxemic]], [[Researcher#CMB|Cryometabolizing]], [[Researcher#NRC|Neurocrygenic]]
|-
|[[Researcher#HDN|Hyperdensificating]]
|[[Researcher#MST|Muscle Stimulating]], [[Researcher#BNM|Bonemending]], [[Researcher#CRG|Carcinogenic]]
|-
|[[Researcher#HTR|Hyperthrottling]]
|[[Researcher#PST|Psychostimulating]], [[Researcher#HLG|Hallucinogenic]]
|-
|[[Researcher#NRS|Neuroshielding]]
|[[Researcher#AOL|Alcoholic]], [[Researcher#BLD|Balding]]
|-
|[[Researcher#AAD|Antiaddictive]]
|[[Researcher#PST|Psychostimulating]], [[Researcher#AHL|Antihallucinogenic]]
|-
|[[Researcher#ADT|Addictive]]
|[[Researcher#PST|Psychostimulating]], [[Researcher#NRT|Neurotoxic]]
|-
|Abominations against god and man.
|[[Researcher#CIP|Ciphering]], [[Researcher#XMB|Crossmetabolizing]]
|-
|}

===Hints===
Dealing with an unknown chemical is like walking blindfolded. The chemical can have any combination of good and bad properties. Discovering what these are will require testing and organized procedures. How to best approach this will be up to the individual researcher. But here are some things to keep in mind:
*You need 30 units of a chemical for the XRF to work. If you don't have enough, you might want to save it until you know the recipe. If you scan a chemical with the XRF, you will know everything about the chemical's properties, given enough clearance.
*Pay attention to research notes brought back from the colony. Colony notes can describe chemicals that are much stronger than the ones you can discover in the lab.
*You can scan basic chemicals like Peridaxon and Oxycodone for properties like painkilling and organ-stabilizing.
*Scanning any new chemical without requested clearance will still give you points, including xenomorph blood.
*There are only 6 chemicals possible in hydroponics, 3 are clearance one and the other 3 are clearance two.
*Distributing a new chemical can still get you in trouble if you overlooked a really bad effect.
*If you can't rely on the marines to bring back research materials, you can try to kick-start your research by mutating plants in hydroponics.
*Your goal is not to get every single person a sample of your new drug, but to help as many as possible. Use the Turing Dispenser for mass production and persuade your superiors to assist with the distribution.

==Chemical Distribution ==
While it might be fun to inject a monkey (or coworkers) with your wonder-drug, your ultimate goal should be to distribute it to where it is most needed. You should always seek the CMO's approval before performing mass distribution, because if an accident happens, it will be ''your'' medical license that is threatened otherwise. Below are some suggestions on how to distribute your chemicals.

{| class="wikitable"
! style="background-color:#A9A9A9; width:100px;" |Picture
! style="background-color:#A9A9A9; width:150px;" |Name
! style="background-color:#A9A9A9;" |Explanation
|-
|[[File:PillBottle.png|64px]]||Pill bottle ||The old classic, but also the slowest in terms of production and ingestion. It's an efficient way to store a lot of chemical volume, but that's the only upside, really.
|-
| [[File:Hypospray.png|64px]]|| Hypospray||An experimental high-end chemical injector, used for instant injections. Can be unlocked using a screwdriver, to allow the vial capsule to be ejected as a magazine. Pairing a hypospray with a vial pouch can be an excellent way for one person to distribute a series of research chemicals in the field.
|-
|[[File:Customautoinjector.png|64px]]||Custom Autoinjector|| If you have a lot of your experimental chemical on hand, then making custom autoinjectors is a good way to distribute it to the masses. A few boxes with empty autoinjectors can be found in your lab. You also can print more of them in Medilathe. You can fill a bunch of autoinjectors easily by loading them in a vial storage box and inserting it into the centrifuge for filling.
|-
|[[File:Acid_harness.png|64px]]||ACID Harness||'''A'''utomated '''C'''hemical '''I'''ntegrated '''D'''elivery Harness. This is the most advanced form of chemical distribution available. Why rely on someone to know when your wonder-drug should be injected and then to actually do it, when you can leave all the work to a computer that does everything for you? The A.C.I.D. will monitor the vital status for its user constantly, and depending on your configuration, automatically inject the chemical from an internal vial into the user. Additionally the A.C.I.D. will never overdose its user.

While the storage slots in the A.C.I.D. can technically be used for anything that would fit in the webbing, the A.C.I.D. specifically requires both a battery and a vial inside the storage slots in order to operate. A high capacity cell battery will last approximately 50 minutes.

A couple of harnesses will be available in the test lab, but if you need more then you can make one by filling a black or brown vest webbing with the following items and then using a wirecutter on the webbing: hypospray, health analyzer, battery, radio, cables.

To configure the A.C.I.D., use a multitool/security access tuner on the webbing.

'''A.C.I.D. Core Configuration'''
{| class="wikitable mw-collapsible mw-collapsed"
! style="background-color:#A9A9A9; width:120;" |Config
! style="background-color:#A9A9A9; width:250;" |Type
! style="background-color:#A9A9A9;" |Description
|-
|Injection Amount || Setting|| How much to inject at a time. The A.C.I.D. will recheck its user's condition after 20 seconds for each unit injected to see if the conditions are still true. If it is, then it will proceed to inject again.
|-
|Damage Threshold||Setting||How much damage must be present in any ''damage type'' configuration. If no damage type configurations are enabled, this setting is not used. Damage type configurations are each considered their own condition.
|-
|AND / OR||Setting||To use AND or OR logic for the configuration. For OR configuration, it injects if any condition becomes true. For AND configuration, it injects only if all conditions are true at the same time.
|-
|Brute||Damage||External brute damage.
|-
|Burn || Damage||External burn damage.
|-
|Toxin||Damage ||Internal toxin damage.
|-
|Oxygen||Damage||Internal oxygen damage.
|-
|Genetic||Damage||Genetic cell damage.
|-
|Heart / Liver / Lungs / Kidneys / Brain ||Damage || Damage to the respective organ.
|-
|Vitals Level ||Condition||Whether or not to inject based on vitals type configuration. If this is not enabled, vitals type configurations are ignored.
|-
| Bleeding||Condition||Whether or not the user is bleeding.
|-
|Internal||Condition||Whether or not the user has internal bleeding.
|-
| Bloodloss||Condition||Whether or not the user has less than 40% blood.
|-
|Fracture ||Condition||Whether or not the user has a bone fracture.
|-
|Splinted ||Condition ||Whether or not the user is wearing a splint.
|-
|Organ damage||Condition|| Whether or not an organ has 10 or more damage.
|-
|Organ failure||Condition||Whether or not an organ has 30 or more damage.
|-
|Death||Condition||Whether or not the user is currently dead.
|-
|Defibrillation||Condition|| Whether or not the user has just been defibrillated.
|-
|Concussion|| Condition||Whether or not the user has been knocked down or knocked out.
|-
|Intoxication ||Condition|| Whether or not the user is dazed, slowed, confused, drowsy, dizzy or hallucinating.
|-
|Foreign Object||Condition|| Whether or not the user contain a foreign object.
|-
|Optimal||Vitals||User is 100% healthy.
|-
| Nominal||Vitals||User is between 80-100% healthy.
|-
|Low||Vitals||User is between 40-80% healthy.
|-
|Very Low||Vitals||User is between 10-40% healthy.
|-
|Critical||Vitals||User is between -10-10% healthy.
|-
| Emergency ||Vitals||User is less than -10% healthy, but not dead.
|-
|}
|-
| [[File:Delivery_med.png|64px]]||Requisitions Delivery Unit||If you want Requisitions to send your chemicals to the surface for you, then you can use this delivery chute to send any item directly down to the Requisitions.
|-
|}

=Alien Research: Xenology=
The art of Xenology. Throughout the operation you will have the opportunity to conduct preliminary research on the Aliens. While this research is more esoteric in nature, providing technical data for the Marine Corps and the Company to use.

At its core, Xenology is accomplished by analyzing alien blood and other liquids, storing dead alien bodies in the research containers, and containing a live alien in the research pen.

===Xenology Corpse Specimen Study===
Marines should be delivering corpses to the Almayer and subsequently to Research for storage and further study. Simply having dead Xenos in Containment will prove a boon to the USCM and generate Tech Points. But their blood and acidic heart will also prove useful subjects to research.

Along with harvesting their blood you can also harvest their acidic heart, to do this you need to cut open their exoskeletons with the circular saw starting from the xenos head, further open up the cut with retractors, separate the organ from the various internal connections, and finally remove the organ using the hemostat. (Aim Head - [[File:1Saw.png|32px|link=|Saw]]->[[File:1Retractor.png|32px|link=|Retractor]]->[[File:1Scalpel.png|32px|link=|Scalpel]]->[[File:1Hemostat.png|32px|link=|Hemostat]])The removed organ can then be analyzed in the analyzer near the cryotube for biomass points.

Larger Xenos have thicker chitin on their exoskeletons, you need to use a laser scalpel (printable from the biomass analyzer) instead of the circular saw. (Aim Head -[[File:Laser scalpel basic.png|32x32px|Saw]] ->[[File:1Retractor.png|32px|link=|Retractor]]->[[File:1Scalpel.png|32px|link=|Scalpel]]->[[File:1Hemostat.png|32px|link=|Hemostat]])

====Xenology Blood Research====
Each alien will have two or more unique liquids/blood samples to collect. To analyze alien blood you will need a corpse, an empty beaker, and either a syringe or an IV Drip. After collecting the blood sample, you can place it into a Chemical Centrifuge or the ChemMaster to split them. Afterwards, you can analyze the samples at the XRF Scanner. Each xenomorph has 560 'units' of blood - and it is split equally between whatever chemicals are present. For instance, a runner will have 280 units of catecholamine plasma, and 280 units of acidic blood. A queen will have 112 units of Dark Acidic Blood, 112 units of Pheromone Plasma, 112 units of Chitin Plasma, 112 units of Neurotoxin Plasma, and 112 units of Royal Plasma. Once this is drained, the xenomorph corpse is empty - if it is alive, however, it will slowly regenerate.

=====Xeno Blood properties:=====
*Acidic Blood - Deals 3 burn damage.
*Dark Acidic Blood - Deals 6 burn damage.
*Pheromone Plasma - Makes you high, '''fixes stuttering, confusion, blurry vision, drowsiness, dizziness, and jitteriness.'''
*Catecholamine Plasma - '''Makes you faster'''.
*Chitin Plasma - '''Prevents fractures.'''
*Neurotoxin Plasma - Deals 7 brain damage, deals 1 toxin damage, makes you jittery and hallucinate.
*Anti-Neurotoxin - '''Neuro-Shielding, Prevents being stunned by all neurotoxin.'''
*Purple Plasma - Deals 2 brute damage.
*Egg Plasma - Infects with Xeno larva, '''useful in research'''.
*Royal Plasma - Makes you addicted, deals 4 brute damage, makes you hallucinate, makes you high, makes you jittery, '''useful in research'''.

===Xenology Live Specimen Study ===
You will need the Marines' assistance in securing egg samples, To grow a Xeno, you will need a monkey in a containment cell and an egg, plant the Egg In the containment cell, then wait.

'''HOWEVER,''' making Xenos on their own is not useful and is actually be more of a detriment. This might stall the game out, and if the proper precautions were not taken, Xenos may even break out of containment. Not very good.

The better solution is making '''Corrupted Hive'''. These are '''''potentially''''' friendly Xenos that can be used to help in combat and ship security.

====Materials====
*Clearance Level 5X
*Egg plasma - extracted from Xeno eggs
* Royal plasma - extracted from an Empress OR can be made by mixing Egg Plasma and Dark Acidic Blood (extracted from a praetorian)

====Let's Start Making Xenos ====
*Make sure you have Level 5X clearance.
*Scan or re-scan Royal Plasma.
*Relate with a randomized chemical one unique property of Royal Plasma in the Synthesis Simulator, called Ciphering. It will cost 10 points. Different levels of unique properties will make different Xeno hives. Level 2 - Corrupt, Level 3 - Alpha and etc. Level 2, or Corrupt hives, are the only ones that can be made that are friendly.
*Make sure the monkey you are using is connected to a blood supply, such as an IV, as the monkey will lose a lot of blood in this process. It will also take some time to gestate.
*Infect monkey with an egg, or by injecting Egg plasma.
* Inject 5 units of your chemical containing Ciphering 2 before the larva hatches.
*Good work! This may take some time before the Corrupted Hive hatches so be patient. Do not try to speed up the process.

=Dropship Upgrade=

You have been provided tools and opportunity to create an upgrade for dropships. This upgrade, when done correctly, allows Pilots to see through their camera with night vision or with increased field of view. This is particularly beneficial for CAS as they can see what they are firing at.

To start making it, you will need to find the property Photosensitive or Crystallization. The first gives night vision, the other gives an increase of view.
The power of matrix depends on the level of the properties, there can also be only one upgrade at a time, so choose carefully. After you found properties, print the matrix assembly at the autolathe, directly south of the medilathe. Insert the vial with the chemical in the matrix, make sure its full, free of any contaminants and contains the chemical with the said property, '''you cannot remove the vial after it`s inserted''' screw the matrix shut and tell a pilot to insert it into his weapons console. You can also insert an empty matrix to reset the upgrades.

=Hydroponics Research=
<big>'''Note that hydroponics is currently undergoing a rework, much of the information here is subject to change.'''</big>

Hydroponics is the process of growing plants without soil. The Company has provided The USS Almayer's research wing with a hydroponics laboratory. Here, researchers can grow and experiment with plant genetics.

{| style="width: 100%; border: none"
| style="width: 100%; vertical-align: top;" |<tabs>
<tab name="Machines">

{| style="border: 2px solid black; class="mw-collapsible"
! style="background-color:#A9A9A9; width:100;"|'''Machine:'''
! style="background-color:#A9A9A9;"|'''Description:'''
|-
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" |[[File:Hydroponicstray.png|64px]]<br>'''Hydroponics tray '''<br>'''
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | A specialised tray to grow plants in. You may right-click the tray and select '''Flush Tray''' to reset it, removing everything including nutrients and refill it with water. The lights on the tray correspond to the state of the plant:
*'''Green:''' Plant is ready to be harvested.
*'''Red:''' Plant is unhealthy, old-aged or dead.
*'''Orange/Red flash:''' High amount of weeds or pests.
*'''Yellow:''' Low amounts of nutrients in the tray.
*'''Blue:''' Low amount of water in the tray.
|-
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" |[[File:Seedvendor.png|64px]]<br>'''MegaSeed Servitor'''
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | Vendor that contains the basic seeds needed to get started.
|-
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" |[[File:Seedextractor.png|64px]]<br>'''Seed extractor <br>'''
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | Extracts seeds from harvested plants. Insert a plant sample to obtain seeds.
|-
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" |[[File:Centrifuge.png|64px]]<br>'''Lysis-isolation Centrifuge'''
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | By inserting a flora data disk and any plant material (such as seeds or samples), this machine allows you to process the genome of said plant. The plant material is destroyed in the process.

Once analyzed, a set of genes can be extracted. This can be done only a certain number of times before the genes decay completely. The extracted data is saved to the floral data disk. This disk can then be used in the Bioballistic delivery system.
|-
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" |[[File:Bioballistic.png|64px]]<br>'''Bioballistic delivery system.'''
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | Uses data disks with extracted genomes from the Lysis-isolation Centrifuge. By inserting a disk and a target plant sample, you can override the existing gene with the stored one. Use this to positively select your plants. If you modify a sample genome too many times, the genome will decay completely.
|}
</tab>
<tab name="Items">

{| style="border: 2px solid black; class="mw-collapsible"
! style="background-color:#A9A9A9; width:100;"|'''Item:'''
! style="background-color:#A9A9A9;"|'''Description:'''
|-
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" |[[File:Floradisk.png|64px]]<br>'''Flora data disk '''<br>'''
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | Data disk for storing plant genes. Used with the lysis-isolation centrifuge and bioballistic delivery system. Can only contain a single gene. Empty data disks can be found in the flora disk boxes inside the hydroponics locker. They can also be stored in the disk cabinet for better organization.
|-
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" |[[File:Plantanalyzer.png|64px]]<br>'''Plant analyzer '''<br>'''
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | Used to analyze plants quickly and get a reading of its general properties.
|-
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" |[[File:Hoe.png|64px]]<br>'''Mini hoe '''<br>'''
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | The mini garden hoe can be used to uproot weeds from hydroponics trays. Using the garden hoe will damage the plant slightly.
|-
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" |[[File:Plantclipper.png|64px]]<br>'''Plant Clippers '''<br>'''
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | A specialised clipping tool for taking samples off plants. Use this if you want a sample from a plant before maturity, or if you want to harvest without removing the plant completely. Alternatively, other cutting tools may be used.
|-
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" |[[File:Hatchet.png|64px]]<br>'''Hatchet '''<br>'''
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | Used to cut down large plants into smaller parts. Usually wood.
|-
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" |[[File:Spade.png|64px]]<br>'''Spade '''<br>'''
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | Used to move dirt around. But we don't have dirt onboard, so it has little purpose right now.
|-
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" |[[File:Bucket.png|64px]]<br>'''Bucket '''<br>'''
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | Its a bucket. Fill it with water and pour it somewhere.
|-
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" |[[File:Plantbag.png|64px]]<br>'''Plant bag '''<br>'''
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | Lets you carry a large amount of plant goods around. Click on a tile to store all the plants on that tile in the bag. Use the bag again to drop everything on another tile.
|-
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" |[[File:Hydroponicsspray.png|64px]]<br>'''Hydroponics spray '''<br>'''
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | Functions similarly to a space cleaner spray. Comes with ammonia. You might want to empty it and fill it with your own special mixture. You can spray this on hydroponics trays to add chemicals to them.
</tab>
<tab name="How to do Hydroponics Research">

{| style="border: 2px solid black; class="mw-collapsible"
! style="background-color:#A9A9A9; width:100;"|'''Subject:'''
! style="background-color:#A9A9A9;"|'''Description:'''
|-
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | <br>'''Identifying Genes '''<br>'''
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | Modifying your plants can require a lot of work and you may want to take notes during it. Gene labels are reordered and randomized each round, so identifying them requires some trial an error in figuring out which gene corresponds to what trait. Using the plant analyzer will be a great help during this. If you see a plant has a desired trait, try to extract one gene at a time from that plant and apply it to another. Once you see that the desired changes have occurred, you've identified the gene. '''A gene label represents the same trait across all plants'''.

Some traits won't do much, while others can have drastic effects.
|-
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | <br>'''Mutating plants '''<br>'''
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | Radioactive compounds might mutate your plants. Unlike the above process, this relies on RNG. It can kill the plant, change its properties or create an entirely new species. The plant might even start producing new chemicals. To mutate a plant, you need to put 60-120u of [[#mutagen|Unstable Mutagen]] in the hydroponics tray that contains the plant you wish to mutate.
|-
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | <br>'''Keeping your plants alive '''<br>'''
|style="border: 2px solid black; border-bottom: 2px solid black; padding: 5px;" | Plants are living things and they can die of old age or if not taken care of. Make sure to remove pests and weeds. Some chemicals are beneficial and provides nutrients, while others can be toxic. If your plant is unhealthy, it might contain a lot of toxins, be weeded or contain pests. Providing your plants with water and nutrients will make them slowly heal.
</tab>
</tabs>
|}

==Your Skillset==
{{MarineSkills
|endurance=1
|medical=3
|surgery=2
|research=1
|intel=1
}}

To find out about how the skill system works head over to the [http://cm-ss13.com/wiki/The_Skill_System skills system page].

= Additional User made information=
*[https://forum.cm-ss13.com/tag/guide:research Research tagged guides] on the CM Forums
*(Outdated) [https://cm-ss13.com/forums/showthread.php?3414-Magnus-Opus-on-Reasearch-by-Cory-Paulson Magnum Opus on Research] by Cory Paulson

Guide to Git

2025-12-02T08:57:29Z

Drulikar: /* Step 7: Finishing Up */ Add note about maybe uninstalling node

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Download and Install Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

You will also likely want to disable actions running on your fork:

[[File:Fork Actions Settings.png|alt=You can disable actions from running on your fork by going to settings, general under actions, disable actions, and save.|frameless|655x655px]]

=== Step 3: Download and Install Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

=== Step 4: Clone Repository ===
Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of <nowiki>https://github.com/</nowiki>[YOURUSERNAME]/cmss13. Then, select a folder (see notes below) to download the repo into, and let it run. It may take awhile.

'''Important''': Be sure the folder you clone to is not a sub-directory of another repository (e.g. another copy of CM). Otherwise you may have problems building.

'''Important''': Be sure the folder you clone to is not a folder managed by OneDrive or any other cloud storage service else you are going to have a bad time ever OneDrive locks a file or offloads a file from your computer onto the cloud to save space. If you allowed your system to use OneDrive this likely means your entire User folder (including documents and desktop) are all managed by OneDrive.

=== Step 5: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

[[File:recommended_extensions.png|400px]]

=== Step 6: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* If you installed Byond in a non-default location, add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

'''Note''': As of writing, BYOND 515.1633+ is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3). However, 516.1668+ do not currently have working breakpoints as of dm-langserver 1.10.0+22 using auxtools commit: v2.3.5.
[[File:Language Client Settings.png|655x655px]]

=== Step 7: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

'''Note:''' If you run into problems building ("Bun failed..."), and happen to have Node installed on your computer, try either updating Node or uninstalling Node.

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

If you are making a change that doesn't require the ground map or ship map loaded, you can speed up the loading process by using a streamlined map. You can either do this using a debugging launch option or by adding/editing the next_map.json file in your data folder to load USS Runtime instead:
[[File:VSC Launch Options.png|right|frameless|423x423px]]
data/next_map.json:<syntaxhighlight lang="json">
{
"map_name": "USS Runtime",
"map_path": "map_files/USS_Runtime",
"map_file": "USS_Runtime.dmm",
"survivor_types": [
"/datum/equipment_preset/survivor/scientist/lv"
],
"traits": [
{
"Marine Main Ship": true,
"Up": 1
},
{
"Marine Main Ship": true,
"Down": -1
}
],
"camouflage": "classic",
"disable_ship_map": true
}

</syntaxhighlight>

=== Step 4: Setting up Git to Commit ===
In order to be able to commit changes, Git needs to know who you are. This requires an email and a username - in most cases, your username should be the same as your GitHub username. The email address can be either an email you're okay with people knowing - or the private email provided by GitHub. This can be obtained at [https://github.com/settings/email https://github.com/settings/emails] under the "Keep my email address private" setting.

Then, you need to open a new Terminal window inside Visual Studio Code. Using the top bar, navigate to 'Terminal' and 'New Terminal'. A window should appear at the bottom of your screen, containing a command line interface. Run the following commands:<pre>
git config --global user.email "your@email.here"
git config --global user.name "yourusernamehere"
</pre>

=== Step 5: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You should give it a commit message on the box with “Message” (otherwise a page will open requiring you to fill out a message that you need to save and close), and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 6: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your fork will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix. Everything above the merge conflict marker will be one side of the merge, and conversely everything below the merge conflict marker will be the other side of the merge.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

Guide to Git

2025-11-04T03:54:10Z

Drulikar: /* Step 6: Configuring Language Client */

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Download and Install Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

You will also likely want to disable actions running on your fork:

[[File:Fork Actions Settings.png|alt=You can disable actions from running on your fork by going to settings, general under actions, disable actions, and save.|frameless|655x655px]]

=== Step 3: Download and Install Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

=== Step 4: Clone Repository ===
Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of <nowiki>https://github.com/</nowiki>[YOURUSERNAME]/cmss13. Then, select a folder (see notes below) to download the repo into, and let it run. It may take awhile.

'''Important''': Be sure the folder you clone to is not a sub-directory of another repository (e.g. another copy of CM). Otherwise you may have problems building.

'''Important''': Be sure the folder you clone to is not a folder managed by OneDrive or any other cloud storage service else you are going to have a bad time ever OneDrive locks a file or offloads a file from your computer onto the cloud to save space. If you allowed your system to use OneDrive this likely means your entire User folder (including documents and desktop) are all managed by OneDrive.

=== Step 5: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

[[File:recommended_extensions.png|400px]]

=== Step 6: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* If you installed Byond in a non-default location, add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

'''Note''': As of writing, BYOND 515.1633+ is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3). However, 516.1668+ do not currently have working breakpoints as of dm-langserver 1.10.0+22 using auxtools commit: v2.3.5.
[[File:Language Client Settings.png|655x655px]]

=== Step 7: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

If you are making a change that doesn't require the ground map or ship map loaded, you can speed up the loading process by using a streamlined map. You can either do this using a debugging launch option or by adding/editing the next_map.json file in your data folder to load USS Runtime instead:
[[File:VSC Launch Options.png|right|frameless|423x423px]]
data/next_map.json:<syntaxhighlight lang="json">
{
"map_name": "USS Runtime",
"map_path": "map_files/USS_Runtime",
"map_file": "USS_Runtime.dmm",
"survivor_types": [
"/datum/equipment_preset/survivor/scientist/lv"
],
"traits": [
{
"Marine Main Ship": true,
"Up": 1
},
{
"Marine Main Ship": true,
"Down": -1
}
],
"camouflage": "classic",
"disable_ship_map": true
}

</syntaxhighlight>

=== Step 4: Setting up Git to Commit ===
In order to be able to commit changes, Git needs to know who you are. This requires an email and a username - in most cases, your username should be the same as your GitHub username. The email address can be either an email you're okay with people knowing - or the private email provided by GitHub. This can be obtained at [https://github.com/settings/email https://github.com/settings/emails] under the "Keep my email address private" setting.

Then, you need to open a new Terminal window inside Visual Studio Code. Using the top bar, navigate to 'Terminal' and 'New Terminal'. A window should appear at the bottom of your screen, containing a command line interface. Run the following commands:<pre>
git config --global user.email "your@email.here"
git config --global user.name "yourusernamehere"
</pre>

=== Step 5: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You should give it a commit message on the box with “Message” (otherwise a page will open requiring you to fill out a message that you need to save and close), and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 6: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your fork will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix. Everything above the merge conflict marker will be one side of the merge, and conversely everything below the merge conflict marker will be the other side of the merge.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

Guide to Git

2025-10-28T02:11:21Z

Drulikar: /* Step 5: Committing your Changes */ Mentioned commit message behavior

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Download and Install Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

You will also likely want to disable actions running on your fork:

[[File:Fork Actions Settings.png|alt=You can disable actions from running on your fork by going to settings, general under actions, disable actions, and save.|frameless|655x655px]]

=== Step 3: Download and Install Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

=== Step 4: Clone Repository ===
Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of <nowiki>https://github.com/</nowiki>[YOURUSERNAME]/cmss13. Then, select a folder (see notes below) to download the repo into, and let it run. It may take awhile.

'''Important''': Be sure the folder you clone to is not a sub-directory of another repository (e.g. another copy of CM). Otherwise you may have problems building.

'''Important''': Be sure the folder you clone to is not a folder managed by OneDrive or any other cloud storage service else you are going to have a bad time ever OneDrive locks a file or offloads a file from your computer onto the cloud to save space. If you allowed your system to use OneDrive this likely means your entire User folder (including documents and desktop) are all managed by OneDrive.

=== Step 5: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

[[File:recommended_extensions.png|400px]]

=== Step 6: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* If you installed Byond in a non-default location, add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

'''Note''': As of writing, BYOND 515.1633+ is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3). However, 516.1668 and 516.1669 do not currently have working breakpoints as of dm-langserver 1.10.0+22 using auxtools commit: v2.3.5.
[[File:Language Client Settings.png|655x655px]]

=== Step 7: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

If you are making a change that doesn't require the ground map or ship map loaded, you can speed up the loading process by using a streamlined map. You can either do this using a debugging launch option or by adding/editing the next_map.json file in your data folder to load USS Runtime instead:
[[File:VSC Launch Options.png|right|frameless|423x423px]]
data/next_map.json:<syntaxhighlight lang="json">
{
"map_name": "USS Runtime",
"map_path": "map_files/USS_Runtime",
"map_file": "USS_Runtime.dmm",
"survivor_types": [
"/datum/equipment_preset/survivor/scientist/lv"
],
"traits": [
{
"Marine Main Ship": true,
"Up": 1
},
{
"Marine Main Ship": true,
"Down": -1
}
],
"camouflage": "classic",
"disable_ship_map": true
}

</syntaxhighlight>

=== Step 4: Setting up Git to Commit ===
In order to be able to commit changes, Git needs to know who you are. This requires an email and a username - in most cases, your username should be the same as your GitHub username. The email address can be either an email you're okay with people knowing - or the private email provided by GitHub. This can be obtained at [https://github.com/settings/email https://github.com/settings/emails] under the "Keep my email address private" setting.

Then, you need to open a new Terminal window inside Visual Studio Code. Using the top bar, navigate to 'Terminal' and 'New Terminal'. A window should appear at the bottom of your screen, containing a command line interface. Run the following commands:<pre>
git config --global user.email "your@email.here"
git config --global user.name "yourusernamehere"
</pre>

=== Step 5: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You should give it a commit message on the box with “Message” (otherwise a page will open requiring you to fill out a message that you need to save and close), and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 6: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your fork will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix. Everything above the merge conflict marker will be one side of the merge, and conversely everything below the merge conflict marker will be the other side of the merge.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

Guide to Git

2025-10-28T02:08:55Z

Drulikar: Added mention of launch arguments for runtime map

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Download and Install Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

You will also likely want to disable actions running on your fork:

[[File:Fork Actions Settings.png|alt=You can disable actions from running on your fork by going to settings, general under actions, disable actions, and save.|frameless|655x655px]]

=== Step 3: Download and Install Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

=== Step 4: Clone Repository ===
Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of <nowiki>https://github.com/</nowiki>[YOURUSERNAME]/cmss13. Then, select a folder (see notes below) to download the repo into, and let it run. It may take awhile.

'''Important''': Be sure the folder you clone to is not a sub-directory of another repository (e.g. another copy of CM). Otherwise you may have problems building.

'''Important''': Be sure the folder you clone to is not a folder managed by OneDrive or any other cloud storage service else you are going to have a bad time ever OneDrive locks a file or offloads a file from your computer onto the cloud to save space. If you allowed your system to use OneDrive this likely means your entire User folder (including documents and desktop) are all managed by OneDrive.

=== Step 5: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

[[File:recommended_extensions.png|400px]]

=== Step 6: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* If you installed Byond in a non-default location, add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

'''Note''': As of writing, BYOND 515.1633+ is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3). However, 516.1668 and 516.1669 do not currently have working breakpoints as of dm-langserver 1.10.0+22 using auxtools commit: v2.3.5.
[[File:Language Client Settings.png|655x655px]]

=== Step 7: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

If you are making a change that doesn't require the ground map or ship map loaded, you can speed up the loading process by using a streamlined map. You can either do this using a debugging launch option or by adding/editing the next_map.json file in your data folder to load USS Runtime instead:
[[File:VSC Launch Options.png|right|frameless|423x423px]]
data/next_map.json:<syntaxhighlight lang="json">
{
"map_name": "USS Runtime",
"map_path": "map_files/USS_Runtime",
"map_file": "USS_Runtime.dmm",
"survivor_types": [
"/datum/equipment_preset/survivor/scientist/lv"
],
"traits": [
{
"Marine Main Ship": true,
"Up": 1
},
{
"Marine Main Ship": true,
"Down": -1
}
],
"camouflage": "classic",
"disable_ship_map": true
}

</syntaxhighlight>

=== Step 4: Setting up Git to Commit ===
In order to be able to commit changes, Git needs to know who you are. This requires an email and a username - in most cases, your username should be the same as your GitHub username. The email address can be either an email you're okay with people knowing - or the private email provided by GitHub. This can be obtained at [https://github.com/settings/email https://github.com/settings/emails] under the "Keep my email address private" setting.

Then, you need to open a new Terminal window inside Visual Studio Code. Using the top bar, navigate to 'Terminal' and 'New Terminal'. A window should appear at the bottom of your screen, containing a command line interface. Run the following commands:<pre>
git config --global user.email "your@email.here"
git config --global user.name "yourusernamehere"
</pre>

=== Step 5: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You can give it a commit message on the box with “Message”, and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 6: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your fork will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix. Everything above the merge conflict marker will be one side of the merge, and conversely everything below the merge conflict marker will be the other side of the merge.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

File:VSC Launch Options.png

2025-10-28T02:04:19Z

Drulikar:

Debugging Launch Options in VSC

Guide to Git

2025-10-28T02:00:31Z

Drulikar: /* Step 5: Download Extensions */

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Download and Install Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

You will also likely want to disable actions running on your fork:

[[File:Fork Actions Settings.png|alt=You can disable actions from running on your fork by going to settings, general under actions, disable actions, and save.|frameless|655x655px]]

=== Step 3: Download and Install Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

=== Step 4: Clone Repository ===
Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of <nowiki>https://github.com/</nowiki>[YOURUSERNAME]/cmss13. Then, select a folder (see notes below) to download the repo into, and let it run. It may take awhile.

'''Important''': Be sure the folder you clone to is not a sub-directory of another repository (e.g. another copy of CM). Otherwise you may have problems building.

'''Important''': Be sure the folder you clone to is not a folder managed by OneDrive or any other cloud storage service else you are going to have a bad time ever OneDrive locks a file or offloads a file from your computer onto the cloud to save space. If you allowed your system to use OneDrive this likely means your entire User folder (including documents and desktop) are all managed by OneDrive.

=== Step 5: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

[[File:recommended_extensions.png|400px]]

=== Step 6: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* If you installed Byond in a non-default location, add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

'''Note''': As of writing, BYOND 515.1633+ is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3). However, 516.1668 and 516.1669 do not currently have working breakpoints as of dm-langserver 1.10.0+22 using auxtools commit: v2.3.5.
[[File:Language Client Settings.png|655x655px]]

=== Step 7: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

If you are making a change that doesn't require the ground map or ship map loaded, you can speed up the loading process by using a streamlined next_map.json file in your data folder to load USS Runtime instead:<syntaxhighlight lang="json">
{
"map_name": "USS Runtime",
"map_path": "map_files/USS_Runtime",
"map_file": "USS_Runtime.dmm",
"survivor_types": [
"/datum/equipment_preset/survivor/scientist/lv"
],
"traits": [
{
"Marine Main Ship": true,
"Up": 1
},
{
"Marine Main Ship": true,
"Down": -1
}
],
"camouflage": "classic",
"disable_ship_map": true
}

</syntaxhighlight>

=== Step 4: Setting up Git to Commit ===
In order to be able to commit changes, Git needs to know who you are. This requires an email and a username - in most cases, your username should be the same as your GitHub username. The email address can be either an email you're okay with people knowing - or the private email provided by GitHub. This can be obtained at [https://github.com/settings/email https://github.com/settings/emails] under the "Keep my email address private" setting.

Then, you need to open a new Terminal window inside Visual Studio Code. Using the top bar, navigate to 'Terminal' and 'New Terminal'. A window should appear at the bottom of your screen, containing a command line interface. Run the following commands:<pre>
git config --global user.email "your@email.here"
git config --global user.name "yourusernamehere"
</pre>

=== Step 5: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You can give it a commit message on the box with “Message”, and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 6: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your fork will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix. Everything above the merge conflict marker will be one side of the merge, and conversely everything below the merge conflict marker will be the other side of the merge.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

Guide to Git

2025-10-28T01:59:44Z

Drulikar: /* Step 1: Downloading Visual Studio Code */

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Download and Install Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

You will also likely want to disable actions running on your fork:

[[File:Fork Actions Settings.png|alt=You can disable actions from running on your fork by going to settings, general under actions, disable actions, and save.|frameless|655x655px]]

=== Step 3: Download and Install Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

=== Step 4: Clone Repository ===
Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of <nowiki>https://github.com/</nowiki>[YOURUSERNAME]/cmss13. Then, select a folder (see notes below) to download the repo into, and let it run. It may take awhile.

'''Important''': Be sure the folder you clone to is not a sub-directory of another repository (e.g. another copy of CM). Otherwise you may have problems building.

'''Important''': Be sure the folder you clone to is not a folder managed by OneDrive or any other cloud storage service else you are going to have a bad time ever OneDrive locks a file or offloads a file from your computer onto the cloud to save space. If you allowed your system to use OneDrive this likely means your entire User folder (including documents and desktop) are all managed by OneDrive.

=== Step 5: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

Also - search for and install GitLens. It makes using the source control features of Visual Studio Code much easier.

[[File:recommended_extensions.png|400px]]

=== Step 6: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* If you installed Byond in a non-default location, add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

'''Note''': As of writing, BYOND 515.1633+ is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3). However, 516.1668 and 516.1669 do not currently have working breakpoints as of dm-langserver 1.10.0+22 using auxtools commit: v2.3.5.
[[File:Language Client Settings.png|655x655px]]

=== Step 7: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

If you are making a change that doesn't require the ground map or ship map loaded, you can speed up the loading process by using a streamlined next_map.json file in your data folder to load USS Runtime instead:<syntaxhighlight lang="json">
{
"map_name": "USS Runtime",
"map_path": "map_files/USS_Runtime",
"map_file": "USS_Runtime.dmm",
"survivor_types": [
"/datum/equipment_preset/survivor/scientist/lv"
],
"traits": [
{
"Marine Main Ship": true,
"Up": 1
},
{
"Marine Main Ship": true,
"Down": -1
}
],
"camouflage": "classic",
"disable_ship_map": true
}

</syntaxhighlight>

=== Step 4: Setting up Git to Commit ===
In order to be able to commit changes, Git needs to know who you are. This requires an email and a username - in most cases, your username should be the same as your GitHub username. The email address can be either an email you're okay with people knowing - or the private email provided by GitHub. This can be obtained at [https://github.com/settings/email https://github.com/settings/emails] under the "Keep my email address private" setting.

Then, you need to open a new Terminal window inside Visual Studio Code. Using the top bar, navigate to 'Terminal' and 'New Terminal'. A window should appear at the bottom of your screen, containing a command line interface. Run the following commands:<pre>
git config --global user.email "your@email.here"
git config --global user.name "yourusernamehere"
</pre>

=== Step 5: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You can give it a commit message on the box with “Message”, and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 6: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your fork will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix. Everything above the merge conflict marker will be one side of the merge, and conversely everything below the merge conflict marker will be the other side of the merge.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

Guide to Git

2025-10-28T01:58:31Z

Drulikar: /* Step 4: Clone Repository */

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Downloading Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

You will also likely want to disable actions running on your fork:

[[File:Fork Actions Settings.png|alt=You can disable actions from running on your fork by going to settings, general under actions, disable actions, and save.|frameless|655x655px]]

=== Step 3: Download and Install Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

=== Step 4: Clone Repository ===
Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of <nowiki>https://github.com/</nowiki>[YOURUSERNAME]/cmss13. Then, select a folder (see notes below) to download the repo into, and let it run. It may take awhile.

'''Important''': Be sure the folder you clone to is not a sub-directory of another repository (e.g. another copy of CM). Otherwise you may have problems building.

'''Important''': Be sure the folder you clone to is not a folder managed by OneDrive or any other cloud storage service else you are going to have a bad time ever OneDrive locks a file or offloads a file from your computer onto the cloud to save space. If you allowed your system to use OneDrive this likely means your entire User folder (including documents and desktop) are all managed by OneDrive.

=== Step 5: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

Also - search for and install GitLens. It makes using the source control features of Visual Studio Code much easier.

[[File:recommended_extensions.png|400px]]

=== Step 6: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* If you installed Byond in a non-default location, add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

'''Note''': As of writing, BYOND 515.1633+ is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3). However, 516.1668 and 516.1669 do not currently have working breakpoints as of dm-langserver 1.10.0+22 using auxtools commit: v2.3.5.
[[File:Language Client Settings.png|655x655px]]

=== Step 7: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

If you are making a change that doesn't require the ground map or ship map loaded, you can speed up the loading process by using a streamlined next_map.json file in your data folder to load USS Runtime instead:<syntaxhighlight lang="json">
{
"map_name": "USS Runtime",
"map_path": "map_files/USS_Runtime",
"map_file": "USS_Runtime.dmm",
"survivor_types": [
"/datum/equipment_preset/survivor/scientist/lv"
],
"traits": [
{
"Marine Main Ship": true,
"Up": 1
},
{
"Marine Main Ship": true,
"Down": -1
}
],
"camouflage": "classic",
"disable_ship_map": true
}

</syntaxhighlight>

=== Step 4: Setting up Git to Commit ===
In order to be able to commit changes, Git needs to know who you are. This requires an email and a username - in most cases, your username should be the same as your GitHub username. The email address can be either an email you're okay with people knowing - or the private email provided by GitHub. This can be obtained at [https://github.com/settings/email https://github.com/settings/emails] under the "Keep my email address private" setting.

Then, you need to open a new Terminal window inside Visual Studio Code. Using the top bar, navigate to 'Terminal' and 'New Terminal'. A window should appear at the bottom of your screen, containing a command line interface. Run the following commands:<pre>
git config --global user.email "your@email.here"
git config --global user.name "yourusernamehere"
</pre>

=== Step 5: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You can give it a commit message on the box with “Message”, and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 6: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your fork will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix. Everything above the merge conflict marker will be one side of the merge, and conversely everything below the merge conflict marker will be the other side of the merge.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

Guide to Git

2025-10-28T01:57:35Z

Drulikar: /* Step 4: Clone Repository */

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Downloading Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

You will also likely want to disable actions running on your fork:

[[File:Fork Actions Settings.png|alt=You can disable actions from running on your fork by going to settings, general under actions, disable actions, and save.|frameless|655x655px]]

=== Step 3: Download and Install Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

=== Step 4: Clone Repository ===
Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of <nowiki>https://github.com/</nowiki>[YOURUSERNAME]/cmss13. Select a folder to download the repo into, and let it run. It may take awhile.

'''Important''': Be sure the folder you clone to is not a sub-directory of another repository (e.g. another copy of CM). Otherwise you may have problems building.

'''Important''': Be sure the folder you clone to is not a folder managed by OneDrive or any other cloud storage service else you are going to have a bad time ever OneDrive locks a file or offloads a file from your computer onto the cloud to save space. If you allowed your system to use OneDrive this likely means your entire User folder (including documents and desktop) are all managed by OneDrive.

=== Step 5: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

Also - search for and install GitLens. It makes using the source control features of Visual Studio Code much easier.

[[File:recommended_extensions.png|400px]]

=== Step 6: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* If you installed Byond in a non-default location, add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

'''Note''': As of writing, BYOND 515.1633+ is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3). However, 516.1668 and 516.1669 do not currently have working breakpoints as of dm-langserver 1.10.0+22 using auxtools commit: v2.3.5.
[[File:Language Client Settings.png|655x655px]]

=== Step 7: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

If you are making a change that doesn't require the ground map or ship map loaded, you can speed up the loading process by using a streamlined next_map.json file in your data folder to load USS Runtime instead:<syntaxhighlight lang="json">
{
"map_name": "USS Runtime",
"map_path": "map_files/USS_Runtime",
"map_file": "USS_Runtime.dmm",
"survivor_types": [
"/datum/equipment_preset/survivor/scientist/lv"
],
"traits": [
{
"Marine Main Ship": true,
"Up": 1
},
{
"Marine Main Ship": true,
"Down": -1
}
],
"camouflage": "classic",
"disable_ship_map": true
}

</syntaxhighlight>

=== Step 4: Setting up Git to Commit ===
In order to be able to commit changes, Git needs to know who you are. This requires an email and a username - in most cases, your username should be the same as your GitHub username. The email address can be either an email you're okay with people knowing - or the private email provided by GitHub. This can be obtained at [https://github.com/settings/email https://github.com/settings/emails] under the "Keep my email address private" setting.

Then, you need to open a new Terminal window inside Visual Studio Code. Using the top bar, navigate to 'Terminal' and 'New Terminal'. A window should appear at the bottom of your screen, containing a command line interface. Run the following commands:<pre>
git config --global user.email "your@email.here"
git config --global user.name "yourusernamehere"
</pre>

=== Step 5: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You can give it a commit message on the box with “Message”, and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 6: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your fork will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix. Everything above the merge conflict marker will be one side of the merge, and conversely everything below the merge conflict marker will be the other side of the merge.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

Guide to Git

2025-10-28T01:54:30Z

Drulikar: Break up steps for cloning, note where not to clone, and note problems with 516.1668 and 516.1669

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Downloading Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

You will also likely want to disable actions running on your fork:

[[File:Fork Actions Settings.png|alt=You can disable actions from running on your fork by going to settings, general under actions, disable actions, and save.|frameless|655x655px]]

=== Step 3: Download and Install Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

=== Step 4: Clone Repository ===
Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”. Be sure its not a OneDrive managed folder (see note below) nor a subdirectory of another repository (e.g. another copy of CM).

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of <nowiki>https://github.com/</nowiki>[YOURUSERNAME]/cmss13. Select a folder to download the repo into, and let it run. It may take awhile.

'''Important''': Be sure not to download and clone the repo into a folder managed by OneDrive or any other cloud storage service else you are going to have a bad time ever OneDrive locks a file or offloads a file from your computer onto the cloud to save space. If you allowed your system to use OneDrive this likely means your entire User folder (including documents and desktop) are all managed by OneDrive.

=== Step 5: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

Also - search for and install GitLens. It makes using the source control features of Visual Studio Code much easier.

[[File:recommended_extensions.png|400px]]

=== Step 6: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* If you installed Byond in a non-default location, add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

'''Note''': As of writing, BYOND 515.1633+ is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3). However, 516.1668 and 516.1669 do not currently have working breakpoints as of dm-langserver 1.10.0+22 using auxtools commit: v2.3.5.
[[File:Language Client Settings.png|655x655px]]

=== Step 7: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

If you are making a change that doesn't require the ground map or ship map loaded, you can speed up the loading process by using a streamlined next_map.json file in your data folder to load USS Runtime instead:<syntaxhighlight lang="json">
{
"map_name": "USS Runtime",
"map_path": "map_files/USS_Runtime",
"map_file": "USS_Runtime.dmm",
"survivor_types": [
"/datum/equipment_preset/survivor/scientist/lv"
],
"traits": [
{
"Marine Main Ship": true,
"Up": 1
},
{
"Marine Main Ship": true,
"Down": -1
}
],
"camouflage": "classic",
"disable_ship_map": true
}

</syntaxhighlight>

=== Step 4: Setting up Git to Commit ===
In order to be able to commit changes, Git needs to know who you are. This requires an email and a username - in most cases, your username should be the same as your GitHub username. The email address can be either an email you're okay with people knowing - or the private email provided by GitHub. This can be obtained at [https://github.com/settings/email https://github.com/settings/emails] under the "Keep my email address private" setting.

Then, you need to open a new Terminal window inside Visual Studio Code. Using the top bar, navigate to 'Terminal' and 'New Terminal'. A window should appear at the bottom of your screen, containing a command line interface. Run the following commands:<pre>
git config --global user.email "your@email.here"
git config --global user.name "yourusernamehere"
</pre>

=== Step 5: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You can give it a commit message on the box with “Message”, and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 6: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your fork will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix. Everything above the merge conflict marker will be one side of the merge, and conversely everything below the merge conflict marker will be the other side of the merge.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

Guide to Git

2025-10-03T11:06:41Z

Drulikar: /* Step 3: Download Git */

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Downloading Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

You will also likely want to disable actions running on your fork:

[[File:Fork Actions Settings.png|alt=You can disable actions from running on your fork by going to settings, general under actions, disable actions, and save.|frameless|655x655px]]

=== Step 3: Download Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of <nowiki>https://github.com/</nowiki>[YOURUSERNAME]/cmss13. Select a folder to download the repo into, and let it run. It may take awhile.

'''Important''': Be sure not to download and clone the repo into a folder managed by OneDrive or any other cloud storage service else you are going to have a bad time ever OneDrive locks a file or offloads a file from your computer onto the cloud to save space. If you allowed your system to use OneDrive this likely means your entire User folder (including documents and desktop) are all managed by OneDrive.

=== Step 4: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

Also - search for and install GitLens. It makes using the source control features of Visual Studio Code much easier.

[[File:recommended_extensions.png|400px]]

=== Step 5: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* Add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

NOTE: As of writing, BYOND 515.1633+ is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3).
[[File:Language Client Settings.png|655x655px]]

=== Step 6: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

If you are making a change that doesn't require the ground map or ship map loaded, you can speed up the loading process by using a streamlined next_map.json file in your data folder to load USS Runtime instead:<syntaxhighlight lang="json">
{
"map_name": "USS Runtime",
"map_path": "map_files/USS_Runtime",
"map_file": "USS_Runtime.dmm",
"survivor_types": [
"/datum/equipment_preset/survivor/scientist/lv"
],
"traits": [
{
"Marine Main Ship": true,
"Up": 1
},
{
"Marine Main Ship": true,
"Down": -1
}
],
"camouflage": "classic",
"disable_ship_map": true
}

</syntaxhighlight>

=== Step 4: Setting up Git to Commit ===
In order to be able to commit changes, Git needs to know who you are. This requires an email and a username - in most cases, your username should be the same as your GitHub username. The email address can be either an email you're okay with people knowing - or the private email provided by GitHub. This can be obtained at [https://github.com/settings/email https://github.com/settings/emails] under the "Keep my email address private" setting.

Then, you need to open a new Terminal window inside Visual Studio Code. Using the top bar, navigate to 'Terminal' and 'New Terminal'. A window should appear at the bottom of your screen, containing a command line interface. Run the following commands:<pre>
git config --global user.email "your@email.here"
git config --global user.name "yourusernamehere"
</pre>

=== Step 5: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You can give it a commit message on the box with “Message”, and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 6: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your fork will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix. Everything above the merge conflict marker will be one side of the merge, and conversely everything below the merge conflict marker will be the other side of the merge.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

Guide to Git

2025-10-03T10:56:45Z

Drulikar: /* Step 3: Download Git */ Add mention of OneDrive

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Downloading Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

You will also likely want to disable actions running on your fork:

[[File:Fork Actions Settings.png|alt=You can disable actions from running on your fork by going to settings, general under actions, disable actions, and save.|frameless|655x655px]]

=== Step 3: Download Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of https://github.com/[YOURUSERNAME]/cmss13. Select a folder to download the repo into, and let it run. It may take awhile.

'''Important''': Be sure not to download and clone the repo into a folder managed by OneDrive or any other cloud storage service else you are going to have a bad time ever OneDrive locks a file or offloads a file from your computer onto the cloud to save space. If you allowed your system to use OneDrive this likely means your entire User folder (including documents and desktop) are all managed by OneDrive.

=== Step 4: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

Also - search for and install GitLens. It makes using the source control features of Visual Studio Code much easier.

[[File:recommended_extensions.png|400px]]

=== Step 5: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* Add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

NOTE: As of writing, BYOND 515.1633+ is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3).
[[File:Language Client Settings.png|655x655px]]

=== Step 6: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

If you are making a change that doesn't require the ground map or ship map loaded, you can speed up the loading process by using a streamlined next_map.json file in your data folder to load USS Runtime instead:<syntaxhighlight lang="json">
{
"map_name": "USS Runtime",
"map_path": "map_files/USS_Runtime",
"map_file": "USS_Runtime.dmm",
"survivor_types": [
"/datum/equipment_preset/survivor/scientist/lv"
],
"traits": [
{
"Marine Main Ship": true,
"Up": 1
},
{
"Marine Main Ship": true,
"Down": -1
}
],
"camouflage": "classic",
"disable_ship_map": true
}

</syntaxhighlight>

=== Step 4: Setting up Git to Commit ===
In order to be able to commit changes, Git needs to know who you are. This requires an email and a username - in most cases, your username should be the same as your GitHub username. The email address can be either an email you're okay with people knowing - or the private email provided by GitHub. This can be obtained at [https://github.com/settings/email https://github.com/settings/emails] under the "Keep my email address private" setting.

Then, you need to open a new Terminal window inside Visual Studio Code. Using the top bar, navigate to 'Terminal' and 'New Terminal'. A window should appear at the bottom of your screen, containing a command line interface. Run the following commands:<pre>
git config --global user.email "your@email.here"
git config --global user.name "yourusernamehere"
</pre>

=== Step 5: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You can give it a commit message on the box with “Message”, and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 6: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your fork will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix. Everything above the merge conflict marker will be one side of the merge, and conversely everything below the merge conflict marker will be the other side of the merge.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

Guide to Git

2025-08-13T03:08:45Z

Drulikar: tweak mapping conflict information

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Downloading Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

You will also likely want to disable actions running on your fork:

[[File:Fork Actions Settings.png|alt=You can disable actions from running on your fork by going to settings, general under actions, disable actions, and save.|frameless|655x655px]]

=== Step 3: Download Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of https://github.com/[YOURUSERNAME]/cmss13. Select a folder to download the repo into, and let it run. It may take awhile.

=== Step 4: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

Also - search for and install GitLens. It makes using the source control features of Visual Studio Code much easier.

[[File:recommended_extensions.png|400px]]

=== Step 5: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* Add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

NOTE: As of writing, BYOND 515.1633+ is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3).
[[File:Language Client Settings.png|655x655px]]

=== Step 6: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

If you are making a change that doesn't require the ground map or ship map loaded, you can speed up the loading process by using a streamlined next_map.json file in your data folder to load USS Runtime instead:<syntaxhighlight lang="json">
{
"map_name": "USS Runtime",
"map_path": "map_files/USS_Runtime",
"map_file": "USS_Runtime.dmm",
"survivor_types": [
"/datum/equipment_preset/survivor/scientist/lv"
],
"traits": [
{
"Marine Main Ship": true,
"Up": 1
},
{
"Marine Main Ship": true,
"Down": -1
}
],
"camouflage": "classic",
"disable_ship_map": true
}

</syntaxhighlight>

=== Step 4: Setting up Git to Commit ===
In order to be able to commit changes, Git needs to know who you are. This requires an email and a username - in most cases, your username should be the same as your GitHub username. The email address can be either an email you're okay with people knowing - or the private email provided by GitHub. This can be obtained at [https://github.com/settings/email https://github.com/settings/emails] under the "Keep my email address private" setting.

Then, you need to open a new Terminal window inside Visual Studio Code. Using the top bar, navigate to 'Terminal' and 'New Terminal'. A window should appear at the bottom of your screen, containing a command line interface. Run the following commands:<pre>
git config --global user.email "your@email.here"
git config --global user.name "yourusernamehere"
</pre>

=== Step 5: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You can give it a commit message on the box with “Message”, and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 6: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your fork will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix. Everything above the merge conflict marker will be one side of the merge, and conversely everything below the merge conflict marker will be the other side of the merge.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

Guide to Git

2025-07-14T03:35:47Z

Drulikar: Update incorrect terminology in Staying in Sync

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Downloading Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

You will also likely want to disable actions running on your fork:

[[File:Fork Actions Settings.png|alt=You can disable actions from running on your fork by going to settings, general under actions, disable actions, and save.|frameless|655x655px]]

=== Step 3: Download Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of https://github.com/[YOURUSERNAME]/cmss13. Select a folder to download the repo into, and let it run. It may take awhile.

=== Step 4: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

Also - search for and install GitLens. It makes using the source control features of Visual Studio Code much easier.

[[File:recommended_extensions.png|400px]]

=== Step 5: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* Add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

NOTE: As of writing, BYOND 515.1633+ is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3).
[[File:Language Client Settings.png|655x655px]]

=== Step 6: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

If you are making a change that doesn't require the ground map or ship map loaded, you can speed up the loading process by using a streamlined next_map.json file in your data folder to load USS Runtime instead:<syntaxhighlight lang="json">
{
"map_name": "USS Runtime",
"map_path": "map_files/USS_Runtime",
"map_file": "USS_Runtime.dmm",
"survivor_types": [
"/datum/equipment_preset/survivor/scientist/lv"
],
"traits": [
{
"Marine Main Ship": true,
"Up": 1
},
{
"Marine Main Ship": true,
"Down": -1
}
],
"camouflage": "classic",
"disable_ship_map": true
}

</syntaxhighlight>

=== Step 4: Setting up Git to Commit ===
In order to be able to commit changes, Git needs to know who you are. This requires an email and a username - in most cases, your username should be the same as your GitHub username. The email address can be either an email you're okay with people knowing - or the private email provided by GitHub. This can be obtained at [https://github.com/settings/email https://github.com/settings/emails] under the "Keep my email address private" setting.

Then, you need to open a new Terminal window inside Visual Studio Code. Using the top bar, navigate to 'Terminal' and 'New Terminal'. A window should appear at the bottom of your screen, containing a command line interface. Run the following commands:<pre>
git config --global user.email "your@email.here"
git config --global user.name "yourusernamehere"
</pre>

=== Step 5: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You can give it a commit message on the box with “Message”, and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 6: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your fork will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

Guide to Git

2025-07-14T03:34:47Z

Drulikar: Update uss runtime json per https://github.com/cmss13-devs/cmss13/pull/9848

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Downloading Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

You will also likely want to disable actions running on your fork:

[[File:Fork Actions Settings.png|alt=You can disable actions from running on your fork by going to settings, general under actions, disable actions, and save.|frameless|655x655px]]

=== Step 3: Download Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of https://github.com/[YOURUSERNAME]/cmss13. Select a folder to download the repo into, and let it run. It may take awhile.

=== Step 4: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

Also - search for and install GitLens. It makes using the source control features of Visual Studio Code much easier.

[[File:recommended_extensions.png|400px]]

=== Step 5: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* Add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

NOTE: As of writing, BYOND 515.1633+ is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3).
[[File:Language Client Settings.png|655x655px]]

=== Step 6: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

If you are making a change that doesn't require the ground map or ship map loaded, you can speed up the loading process by using a streamlined next_map.json file in your data folder to load USS Runtime instead:<syntaxhighlight lang="json">
{
"map_name": "USS Runtime",
"map_path": "map_files/USS_Runtime",
"map_file": "USS_Runtime.dmm",
"survivor_types": [
"/datum/equipment_preset/survivor/scientist/lv"
],
"traits": [
{
"Marine Main Ship": true,
"Up": 1
},
{
"Marine Main Ship": true,
"Down": -1
}
],
"camouflage": "classic",
"disable_ship_map": true
}

</syntaxhighlight>

=== Step 4: Setting up Git to Commit ===
In order to be able to commit changes, Git needs to know who you are. This requires an email and a username - in most cases, your username should be the same as your GitHub username. The email address can be either an email you're okay with people knowing - or the private email provided by GitHub. This can be obtained at [https://github.com/settings/email https://github.com/settings/emails] under the "Keep my email address private" setting.

Then, you need to open a new Terminal window inside Visual Studio Code. Using the top bar, navigate to 'Terminal' and 'New Terminal'. A window should appear at the bottom of your screen, containing a command line interface. Run the following commands:<pre>
git config --global user.email "your@email.here"
git config --global user.name "yourusernamehere"
</pre>

=== Step 5: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You can give it a commit message on the box with “Message”, and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 6: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your branch will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

Template:Ability Finesse Description

2025-02-25T23:25:50Z

Drulikar: Changes from https://github.com/cmss13-devs/cmss13/pull/2244 that never made it to the wiki.

'''PASSIVE:''' By slashing enemies, you temporarily increase your movement speed and you also you apply a tag that changes how your two new tail abilities function.

Doctor

2025-02-18T00:47:19Z

Drulikar: /* Field Deployment */ updated per https://github.com/cmss13-devs/cmss13/pull/7857

{{JobPageHeader
|headerbgcolor = #2175d9
|headerfontcolor = white
|stafftype = MEDICAL
|imagebgcolor = lightblue
|img = MD.png
|jobtitle = Almayer Doctor
|difficulty = Medium
|rank = Second Lieutenant
|superior = Chief Medical Officer
|unlock = One hour as Nurse.
|duties = Heal severely injured marines, do surgery.
|guides = [http://cm-ss13.com/wiki/Guide_to_Medicine Guide to Medicine], [http://cm-ss13.com/wiki/Surgery Surgery], [http://cm-ss13.com/wiki/Chemistry Guide to Chemistry]
|description = You are tasked with keeping the marines healthy and strong, usually in the form of surgery.<br>
You are also an expert when it comes to medication and treatment. If you do not know what you are doing, adminhelp so a mentor can assist you.
}}
''"Doctor, I can't feel my legs!"''<br />
''"I know, we amputated them!"''<br />― A Patient and a Doctor

A [[Hospital Corpsman]] can bandage a wounded marine, but sometimes the situation is so bad that the Marine should be taken from combat back to the Almayer. That's where you, the '''Almayer Doctor''' comes, safe in your medbay on the Almayer, you'll be doing all the things normal field medics can't do.

== Role ==
----
Your job as a '''Almayer Doctor''' is '''to heal what the [[Hospital Corpsman|Hospital Corpsmen]] can't'''. You will be responsible for:
* Treating major wounds and infections
* Operating on patients in need of major surgeries
* Concocting medicine as required
* Handling triage

You answer to the '''[[Chief Medical Officer]]''', and should follow their instructions and advice at all times, however if the [[Commanding Officer]] gives you an order it takes priority over the Chief Medical Officers. In the event that you are planning to deploy for field surgery remember that the CMO has to agree to send you planetside. You also share a department with the [[Researcher|Research team]], who usually keep to themselves upstairs, but they will occasionally make a medicinal breakthrough.

=== Tools of the Trade ===
----
The Almayer doctor is given a number of trusty tools to assist him or her in their duty, which is, being a doctor! These tools include:
* Two cryogenic cells
* A chemistry laboratory
* An autodoc medical system
* Four operating theaters
* One sleeper
* Six cryogenic freezers (For placing players who have left the game into)
* Four body scanners
* A ton of medical kits, defibrillators and a bunch of other supplies in the vendors
* Multiple IVs and a supply of blood bags

=== I'm a doctor! Now what? ===
----
At the beginning of each round, you will have 20-30 minutes to prepare the Medbay before injured marines start showing up. During this time, you won't have many injuries to tend with, so it is best to try to prepare for the flood of casualties in Medbay by doing 'common tasks' detailed below. <br />

Common tasks that help improve the effectiveness of your medical environment:
----
{| class="wikitable"
|-
|
[[File:Medbay Cryo Updated.png|thumb|]] <br />Switch the cryogenic cells on by clicking on each individual tank (circled in yellow) to open the cryogenic interface.The gas cooling system (circled in green) cools the cryogenic cells, while the pressure tank (circled in red) maintains pressure in the cells which is required for them to function effectively.
You are able to customize the power and target temperature for the cryogenic cells, but the default configuration is the most efficient. (As an additional improvement, you can alter the cryogenic cells individually with different chemicals, loadable by removing the existing beakers and inserting new beakers filled with your designer chemicals.)
|}
<br />

{| class="wikitable"
|-
| [[File:IVdrip.png|thumb]]Set up the IV drips. || [[File:Bloodtypes table.jpg|thumb]]
|IV drips are used to provide patients with blood. To use them, take a blood pack (or a beaker, if you want to inject chemicals) and use it on the IV drip to load it. After loading the IV drip, pull it to be adjacent to your patient and click-and-drag the IV drip to your patient's body. You should get a message that the IV drip was attached. '''MAKE SURE THAT THE BLOOD IS COMPATIBLE WITH YOUR PATIENT. (See attached chart)''' When in a hurry, use O- blood. (all blood types can take O- blood) ||
|Always unattach the IV drip from the patient if he is about to be moved away. Patients will take minor brute damage if you pull them away while they are still attached. ||
|}

{| class="wikitable"
|-
| [[File:Doctor-Chem.png|400px]] Produce Chemicals at the circled red workstation, and at the circled yellow station make them into pills. || Squad medics have access to the medical communications channel through a medical key available in their lockers. They will likely request that you provide them with certain chemicals as a part of their preparation routine; the chemvendors in the lab share energy with eachother, at times the Researcher might help. Always provide these medications in pill form in a labelled pill bottle. You are authorized to distribute requested <b>beneficial</b> medicine in pill form to Hospital Corpsmen.
|}

* Please refer to the [http://cm-ss13.com/wiki/Chemistry chemistry guide] for details of what is available to create, please see [[Rules|Server Rules]] & [[Marine Law|Marine Law]] for an idea of what is illegal to distribute. Also understand the [[Standard Operating Procedure]] as it applies to Doctor.
<br />

{| class="wikitable"
|-
| [[File:Medibot.png|64px]] Medibots || As a doctor, you are able to construct medibots. Medibots are automated robots designed to assist in triaging the department, or for quick administration of drugs. By default, their injection is 15 Tricordrazine synthesized inside the medibot itself. To see how create a medibot, click [[Guide_to_construction#Other|here]].
|}

=== Surgery ===
----
{| class="wikitable"
|-
| [[File:Prepared-OR.png|400px]] The Upper Left Operating Room, prepared for surgery. Red circle around the surgical tool storage, Yellow circle around the Operating Table || As the round progresses, your main role will be to administer aid to the individuals that visit the Medbay. Since Hospital Corpsman can patch up and resolve minor injuries, marines will typically only visit the Medbay if they have a severe internal injury that requires surgery. As such, it is critical to triage cases properly. Because surgery is a time-consuming process with many separate steps, it is important to be educated on [[Surgery|how to conduct surgery]].
|}

=== Field Deployment ===
----
Generally, only the Field Doctor will deploy from the Almayer to the FOB  for field surgery duty once the area is secured (as early as second drop). As a field surgeon, you are expected to be performing surgery duties in a secure area, not fighting or performing surgery on the front-line. Your Chief Medical Officer, or the assigned or current Commanding Officer, can still forbid/delay/recall deployment else you may face arrest from the Military Police. Sometimes the CMO forbids people to deploy before Medbay is set up, so be sure to help with making pills, printing limbs, filling IV drips, and filling the cryotubes with chemicals before going down. Ultimately the Medbay on the Almayer takes priority, so if it somehow it becomes unmanned the field surgeon should return to the Almayer if they are informed. Additionally, should a Field Doctor wake up late, they are allowed to deploy to relieve any existing field surgeon.



Many maps also have medical departments on the colony, which if repaired, offer shipside Medbay levels of utility. But be sure wherever you do surgery, you are safe. You lack endurance and firearm training like marines do to defend themselves and others. Most marines don't mind guarding a doctor performing surgery in a "relatively" secure area. Just be sure to ask nicely.

Practice diagnosing patients without using the big medical scanner - you may not have access to one in the field unless you bring one with you. Do not leave your patients with organ damage, internal bleeding, or broken bones after surgery.

=== General Guidance ===
----
Nobody likes to wait in the Medbay while they are injured and unconscious. As a doctor, you need to organize your activities and manage your workflow efficiently in order to process patients quickly and reduce the time that everyone has to wait. This can become especially important if you are the only doctor actively conducting surgery. It's equally important to have a thick skin, because most players will be irritated that they were injured to start with.

Remember that you can restock empty injectors, bottles and medical supplies in the medical vendors by click-dragging them back onto it, or by clicking the injector/bottle in hand to re-fill it. This makes them usable again. Pill bottles are not restockable in this manner.

Your actions will have a large impact upon whether or not the marines will be victorious, because your ability to do surgery influences the number of active marines currently engaged in combating the alien menace. Do your job well, but remember - this is not a chore. Perform your duties at your own pace, and most importantly remember to breathe and have fun. <br />

===Efficiency Tips===
----
* Before conducting surgery, always check the body scan of the patient and have it readily available in your mind. If you are unable to remember the scan, don't fret, you can just examine your patient and read up on the saved scan data again for reassurance.
* If the patient has low blood levels and also requires surgery, give them the IV drip '''while''' they are on the surgery table.
* Print mechanical limbs early on in the surgery procedure, or before patients need them, so they are ready immediately when you need them.
* Remember that - thanks to improved technology - you just need to put the patient on a surgery table, then drag his sprite onto the surgery table to hook him up with anesthetics for your operation to commence. Be sure though that there's an anesthetic tank loaded up beforehand!
* The [[Surgery#Incision_Management_System|'''Incision Managment Tool''']] is a godsend when it comes to state of the art surgery procedures. Use this instead of the usual way of a scalpel and retractor. The IMT does all three steps (incision, retracting and bleeder clamping) in one click!
* For a single patient, conduct all required surgeries at once. This reduces the number of times you need to pick up surgery tools. '''For example:''' If a patient has internal bleeding, heart/lung damage, a broken ribcage and shrapnel, cut open his chest, treat the IB with [[Surgery#Fix-O-Vein|Fix-O-Vein]], use a [[Surgery#Hemostat|Hemostat]] to remove the shrapnel, then use a [[Surgery#Advanced_Trauma_Kit|trauma kit]] for the organ damage, retract the skin, use bone gel and the bone setter for the bones and close him up. Done! You can also refer to this [[Surgery#Combining_Surgeries|Guide]] here!
* Don't fight with the other doctors over the operating rooms. Simply wait for it to get vacant instead of arguing with the people around you.
* If a patient does not succumb to anesthesia when you hook him onto the surgery table, check for a collapsed lung! Patients with this type of injury usually suffer from oxygen damage which prevents them from falling asleep. In that case, administer a dosage of Dexalin+ to bridge the time till you fix the lungs.

===Your Skillset===
{{MarineSkills
|endurance=1
|medical=3
|surgery=2
|fireman=1
}}

To find out about how the skill system works head over to the [http://cm-ss13.com/wiki/The_Skill_System skills system page].

===Guides===
* [https://cm-ss13.com/forums/showthread.php?1463-Doctor-101 Doctor 101] by grinkgo on 04-14-2019

Field Doctor

2025-01-16T03:00:27Z

Drulikar: Initial page for alternate role for Doctor.

#REDIRECT [[Doctor]]

Main Page

2024-12-31T22:53:47Z

Drulikar: Removed Out of Rotation from Hybrisa link

__NOTOC__

{{Main Page/Shared}}

<center>[[File:Logo.png|link=http://cm-ss13.com]]</center>

<p align=center>CM-SS13 is a heavily modified [http://www.byond.com/games/Exadv1/SpaceStation13 SS13] server inspired by the ''[http://en.wikipedia.org/wiki/Aliens_(film) Aliens]'' film and built from [https://bay.ss13.me/ Baystation 12]. If you're new to Space Station 13, check out our [[Space Station 13 Guide]]. <b>We are not in any way affiliated with Fox/Disney, or the Aliens IP.</b> This is an entirely fan-made project.</p>

<p align=center>This wiki is entirely community made - you just need to [https://cm-ss13.com/w/index.php?title=Special:UserLogin&returnto=Main+Page sign up] to get started!</p>

{{Main page/search}}

<div id="home-content" class="home-grid">

<div id="home-card-marines" class="home-card home-card--col2 home-card--row3">
<div class="home-card__label">Marines</div>
<div class="home-link">
<div class="home-link__button">[[Marine_Quickstart_Guide | Quickstart Guide]]</div>
<div class="home-link__button">[[Marines | About the Marines]]</div>
<div class="home-link__button">[[Responders | Response Teams]]</div>
<div class="home-link__button">[[Marine_Equipment | Marine Equipment]]</div>
<div class="home-link__button">[[Requisitions]]</div>
<div class="home-link__button">[[Standard Operating Procedure]]</div>
<div class="home-link__button">[[Marine Law]]</div>
<div class="home-link__button">[[Rank]]</div>
</div>
</div>

<div id="home-card-xenos" class="home-card home-card--col2 home-card--row3">
<div class="home-card__label">Xenos</div>
<div class="home-link">
<div class="home-link__button">[[Xeno_Quickstart_Guide | Quickstart Guide]]</div>
<div class="home-link__button">[[Aliens | About the Aliens]]</div>
<div class="home-link__button">[[Hives]]</div>
<div class="home-link__button">[[Pheromones]] </div>
<div class="home-link__button">[[Strains]]</div>
<div class="home-link__button">[https://cm-ss13.com/w/images/5/53/Evolution.png Evolution Diagram] </div>
</div>
</div>

<div id="home-card-other-factions" class="home-card home-card--col2 home-card--row3">
<div class="home-card__label">Other Factions</div>
<div class="home-link">
<div class="home-link__button">[[Hunters]]</div>
<div class="home-link__button">[[UPP]]</div>
<div class="home-link__button">[[The Colonial Liberation Front | CLF]]</div>
<div class="home-link__button">[[Weyland Yutani's PMCs | PMCs]] </div>
<div class="home-link__button">[[The Colonial Marshal Bureau | Colonial Marshal Bureau]]</div>
<div class="home-link__button">[[Dutch's Mercenary Team | Dutch's Dozen]] </div>
<div class="home-link__button">[[Military Contractors | VAIPO Mercenaries]] </div>
</div>
</div>

<div id="home-card-guides" class="home-card home-card--col2 home-card--row3">
<div class="home-card__label">Guides</div>
<div class="home-link">
<div class="home-link__button">[https://forum.cm-ss13.com/c/general/guides/22 Gameplay Guides on the Forum]</div>
<div class="home-link__button">[[Guide to construction | Construction]]</div>
<div class="home-link__button">[[Guide_to_Engineering | Engineering]]</div>
<div class="home-link__button">[[S-52 Fusion Reactor]]</div>
<div class="home-link__button">[[Guide to Medicine | Medicine]]</div>
<div class="home-link__button">[[Surgery]]</div>
<div class="home-link__button">[[Chemistry]]</div>
<div class="home-link__button">[[Researcher | Research]]</div>
<div class="home-link__button">[[Guide_to_Paperwork| Paperwork]] </div>
<div class="home-link__button">[[Cooking]]</div>
<div class="home-link__button">[[Drinks]]</div>
</div>
</div>

<div id="home-card-maps" class="home-card home-card--col2 home-card--row3">
<div class="home-card__label">Maps</div>
<div class="home-link">
<div class="home-link__button">[https://webmap.affectedarc07.co.uk/ WEBMAPS]</div>
<div class="home-link home-grid--col2">
<div class="home-link__button">[http://cm-ss13.com/w/images/5/54/USS_Almayer.png USS Almayer]</div>
<div class="home-link__button">[https://webmap.affectedarc07.co.uk/maps/cm/almayer/ Webmap]</div>
<div class="home-link__button">[https://cm-ss13.com/w/images/6/6f/LV624.png LV-624]</div>
<div class="home-link__button">[https://webmap.affectedarc07.co.uk/maps/cm/lv624/ Webmap]</div>
<div class="home-link__button">[http://cm-ss13.com/w/images/1/18/Map_icecolony.png Shivas Snowball]</div>
<div class="home-link__button">[https://webmap.affectedarc07.co.uk/maps/cm/shivas/ Webmap]</div>
<div class="home-link__button">[http://cm-ss13.com/w/images/7/78/Whiskey_outpost.png Whiskey Outpost]</div>
<div class="home-link__button">[https://webmap.affectedarc07.co.uk/maps/cm/whiskey/ Webmap]</div>
<div class="home-link__button">[https://cm-ss13.com/w/images/9/9e/Solaris_Ridge.png Solaris Ridge]</div>
<div class="home-link__button">[https://webmap.affectedarc07.co.uk/maps/cm/solaris/ Webmap]</div>
<div class="home-link__button">[https://cm-ss13.com/w/images/e/e0/Prison_Station_Science_Annex.png Fiorina Science Annex]</div>
<div class="home-link__button">[https://webmap.affectedarc07.co.uk/maps/cm/fiorina/ Webmap]</div>
<div class="home-link__button">[https://cm-ss13.com/w/images/9/92/Trijent_Dam.png Trijent Dam]</div>
<div class="home-link__button">[https://webmap.affectedarc07.co.uk/maps/cm/trijent/ Webmap]</div>
<div class="home-link__button">[https://cm-ss13.com/w/images/2/21/Sorokyne_Wiki_Map.jpg Sorokyne Strata]</div>
<div class="home-link__button">[https://webmap.affectedarc07.co.uk/maps/cm/sorokyne/ Webmap]</div>
<div class="home-link__button">[https://cm-ss13.com/w/images/0/0d/Kutjevo_a1.jpg Kutjevo Refinery]</div>
<div class="home-link__button">[https://webmap.affectedarc07.co.uk/maps/cm/kutjevo/ Webmap]</div>
<div class="home-link__button">[https://cm-ss13.com/w/images/b/bb/C_claim.png Chance's Claim] </div>
<div class="home-link__button">[https://webmap.affectedarc07.co.uk/maps/cm/lv522/ Webmap]</div>
<div class="home-link__button">[https://cm-ss13.com/w/images/9/94/New_Varadero.png New Varadero]</div>
<div class="home-link__button">[https://webmap.affectedarc07.co.uk/maps/cm/newvaradero/ Webmap]</div>

</div>
<div class="home-link__button">[https://cm-ss13.com/w/images/8/88/Ice_V1.png Ice V1]</div>
<div class="home-link__button">[https://cm-ss13.com/w/images/c/cf/Ice_Colony_v2.png Ice V2]</div>
<div class="home-link__button">[https://cm-ss13.com/w/images/6/60/LV759_Hybrisa_Prospera.png LV-759 Hybrisa Prospera]</div>
<div class="home-link__button">[https://cm-ss13.com/w/images/8/8e/CORSAT_Satellite.png CORSAT <span style="color:red;font-size:0.9em;font-weight:bold">(Out of Rotation)</span>]</div>
<div class="home-link__button">[http://cm-ss13.com/w/images/4/4c/Map_Prison.png Fiorina Cellblocks <span style="color:red;font-size:0.9em;font-weight:bold">(Out of Rotation)</span>] </div>
</div>
</div>

<div id="home-card-other" class="home-card home-card--col2 home-card--row3">
<div class="home-card__label">Other</div>
<div class="home-link">
<div class="home-link__button">[[Rules]]</div>
<div class="home-link__button">[[Helping Out| Wiki Contribution]]</div>
<div class="home-link__button">[[Contributing to the Game]]</div>
<div class="home-link__button">[[FAQ]]</div>
<div class="home-link__button">[[Lore_Home|Lore]]</div>
<div class="home-link__button">[[Slang]]</div>
<div class="home-link__button">[[Alternate Gamemodes]]</div>
<div class="home-link__button">[[Macros and Hotkeys]]</div>
<div class="home-link__button">[[Space_Station_13_Guide#Keybinds|Keybindings]]</div>
</div>
</div>

</div>

Guide to Git

2024-12-16T02:01:12Z

Drulikar: Add mention of USS Runtime for Testing your Code section

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Downloading Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

You will also likely want to disable actions running on your fork:

[[File:Fork Actions Settings.png|alt=You can disable actions from running on your fork by going to settings, general under actions, disable actions, and save.|frameless|655x655px]]

=== Step 3: Download Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of https://github.com/[YOURUSERNAME]/cmss13. Select a folder to download the repo into, and let it run. It may take awhile.

=== Step 4: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

Also - search for and install GitLens. It makes using the source control features of Visual Studio Code much easier.

[[File:recommended_extensions.png|400px]]

=== Step 5: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* Add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

NOTE: As of writing, BYOND 515.1633+ is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3).
[[File:Language Client Settings.png|655x655px]]

=== Step 6: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

If you are making a change that doesn't require the ground map or ship map loaded, you can speed up the loading process by using a streamlined next_map.json file in your data folder to load USS Runtime instead:<syntaxhighlight lang="json">
{
"map_name": "USS Runtime",
"map_path": "map_files/USS_Runtime",
"map_file": "USS_Runtime.dmm",
"survivor_types": [
"/datum/equipment_preset/survivor/scientist/lv"
],
"traits": [{"Marine Main Ship": true}],
"disable_ship_map": true
}

</syntaxhighlight>

=== Step 4: Setting up Git to Commit ===
In order to be able to commit changes, Git needs to know who you are. This requires an email and a username - in most cases, your username should be the same as your GitHub username. The email address can be either an email you're okay with people knowing - or the private email provided by GitHub. This can be obtained at [https://github.com/settings/email https://github.com/settings/emails] under the "Keep my email address private" setting.

Then, you need to open a new Terminal window inside Visual Studio Code. Using the top bar, navigate to 'Terminal' and 'New Terminal'. A window should appear at the bottom of your screen, containing a command line interface. Run the following commands:<pre>
git config --global user.email "your@email.here"
git config --global user.name "yourusernamehere"
</pre>

=== Step 5: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You can give it a commit message on the box with “Message”, and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 6: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your branch will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

CM13 Mapping Crash Course

2024-12-12T04:09:58Z

Drulikar: Changed strongdmm link to the releases page.

{{Important
|Title=This page is a work in progress.
|Note=This page is heavily work in progress. Until it is complete, it is suggested to use this guide. https://hackmd.io/@tgstation/SyVma0dS5#Ingredients
|Color=Cyan
}}

__TOC__

= CM13 Mapping Crash Course =

== '''Disclaimer: BEFORE YOU START!''' ==

This guide assumes you’re using the most recent of StrongDMM, and already have a working
knowledge of how to use Git, and are familiar with CM13's general Git Practices. As long as you
know how Git works, and you have StrongDMM installed you’re ready to start mapping.

* You can learn about Git, and how to use it [https://cm-ss13.com/wiki/Contributing_to_the_Game#Git '''here'''].
* You can read about CM13’s specific Git Practices when they're finished.
* You can get a copy of StrongDMM '''[https://github.com/SpaiR/StrongDMM/releases here]'''.

If you’re looking for the guide on how to make Nightmare Creator (NMC) inserts, it will be here when they're finished.
You can still use Byond’s map editor, but we strongly recommend you use StrongDMM for your own sanity. If you’re using Byond’s built in map editor, or fastDMM you’ll need to use Map.

Merge 2 (hyperlink to how-to-use-section at end of this article) before committing your map(s) to
Git.

Merge Requests with un-merged maps cannot be accepted. You will need to use MM2 or StrongDMM if you want any chance of submitting a mapping change!

For international readers, this guide is written assuming your keyboard is using the US Standard
QWERTY Layout. Some keystrokes may be different, or not work entirely. Unfortunately,
StrongDMM (And Byond’s built in map editor) cannot have their hotkeys rebound.

'''This document is a work in progress, some information may be incorrect, there might be
typos, and some information outright may be missing.'''

== StrongDMM Reference ==
==== File commands ====

{| class="wikitable" style="width:70%"
|-
! Command !! Description
|-
| Open Environment... ||
Opens a dialogue to locate a compiled DME file.

'''Note''': ''Only one DME may be loaded at a
time. Loading a DME will close all map
windows. You will be asked to save all
unsaved changes.''

|-
| Recent Environments...|| Opens a side menu listing recently opened DME files.
|-
| New Map...'''Ctrl + N''' || Creates a new map. You will be asked to enter X and Y bounds, as well as the amount of Z levels to include.

'''Note:''' ''CM13 does not use traditional Z levels, so always enter 1.''
|-
| Open Map… '''Ctrl + O''' || Opens any map on a local hard-disk.

'''Note:''' ''Opening a map will open a new map
window, and will not close any other open
map windows.''
|-
| Open Available Map… '''Ctrl + Shift + O'''|| Opens any map recognized in the current DME.
|-
| Recent Maps || Opens a side menu listing recently opened .dmm files for the currently loaded DME.
|-
| Close Map '''Ctrl + W'''|| Closes the current map window.
|-
| Close All Maps '''Ctrl + Shift + W''' || Closes all open map windows.
|-
| Save '''Ctrl + S''' || Saves current changes to the open map.

'''Note 1:''' ''This will save the currently opened
map using the map format selected in the
Preferences window. Make sure to use the
'''TGM format''' always!''

'''Note 2:''' ''If the currently opened map is of a
different format than the selected format in
preferences, it will be saved in the new
format, even if no changes were made.''

|-
| Save All '''Ctrl + Shift + S'''|| Saves current changes on all maps.
|-
| Save As... || Opens a dialogue to save the current map under an alternate title.

'''Note:''' ''The newly saved version will not be automatically opened in the program. The new file will also not be appended with a valid file extension, you will need to type .dmm yourself in the save dialogue''
|-
| Preferences...|| Opens the program Preferences window.

'''Note''': Make sure you’re configured for CM13
properly.
|-
| Exit '''Ctrl + Q''' || Exits the program.

'''Note''': ''This closes all map windows, you will
be asked to save all unsaved changes before
quit.''
|}

==== Edit Commands ====
{| class="wikitable" style="width:70%"
|-
! Command !! Description
|-
| Undo '''Ctrl + Z'''|| Moves a step back in edit history.

'''Note''': ''One step in edit history is one action,
click, keystroke, etc, that makes a change to
the map that can be saved.''

|-
| Redo '''Ctrl + Shift + Z'''|| Moves a step forward in edit history (if there are any available).
|-
| Cut '''Ctrl + X'''|| Removes the current selection from the map, and adds it to the clipboard.

'''Note''': ''Cut only removes content from the
currently enabled layers.''
|-
| Copy '''Ctrl + C''' || Copies the current selection of the map, and adds it to the clipboard.

'''Note''': ''Copy only copies content from the
currently enabled layers.''
|-
| Paste '''Ctrl + V''' || Pastes the current clipboard at the turf closest to the cursor.

'''Note''': ''The clipboard is always pasted relative
to the bottom left corner of the clipboard
selection.''

|-
| Delete '''Delete''' || Deletes the current selection.

'''Note''': ''Delete only removes objects from the
currently enabled layers.''

|-
| Deselect All '''Ctrl + D'''|| Deselects the current selection.
|-
| Set Map Size... || Opens a dialogue that allows you to edit the X and Y bounds of the map, as well as add or subtract additional Z layers.

'''Note 1''': CM13 does not make use of Z layers
in its map files, as such you shouldn’t need to
ever touch this option.

'''Note 2''': There is no 0,0 coordinate, the origin
coordinate is 1,1 located in the bottom left
corner of the map
|-
| Find Instance… '''Ctrl + F''' || Opens a dialogue that allows you to find all
instances of a certain typepath. Once an object or instance is found, the search results menu will appear, allowing you to jump to each located object, as well as replace the objects via typepath substitution.

Note: This dialogue also functions as the
Find and Replace function native to Byond’s
Map Editor.
|}

==== Options Command ====

{| class="wikitable" style="width:70%"
|-
! Command !! Description
|-
| Layers Filter... || Opens up the Layer Filter menu. Checking the box next to a typepath, enables it. Unmarked boxes are disabled. Permits precise filtering of typepaths.

'''Note''': Layer in mapping terms refers to Areas, Turfs, Objects, and Mobs, and aids in filtering what needs to be viewed while mapping. What actually controls how objects layer in game, is the layer variable locally stored on objects.
|-
| Toggle Area Ctrl + 1 || Toggles the Areas “Layer” appearing.

'''Note''': The Area Layer is never rendered in
game, and can obstruct the cursor during the
mapping process if not disabled.
|-
| Toggle Turf Ctrl + 2 || Toggles the Turf Layer appearing.
|-
| Toggle Object Ctrl + 3 || Toggles the Object Layer appearing.
|-
| Toggle Mob Ctrl + 4 || Toggles the Mob Layer appearing.
|-
| Frame Areas || When enabled, draws a white frame at and
around Area borders, scaling with viewport
zoom level.
|-
| Synchronize Maps View || When enabled, forces all open map windows
viewport cameras to mirror.

'''Note''': This is used to match Z levels together
across map files, since CM13 doesn’t use Z
levels like this, you probably won’t need this
option.
|-
| Screenshot... || Opens the Screenshot dialogue, allowing you
to export either the full view of map, or the
current selection.

'''Note 1''': The “Full” screenshot option does not
work, and renders a black image. To export
your entire map, make a full map selection.

'''Note 2''': The Area Layer, and white borders
from the Frame Areas option will not be
rendered in the screenshot.

'''Note 3''': The .png file extension needs to be
manually typed in the save dialogue. It will
not auto-append. This does not affect the
saving process.
|}

==== Window Commands ====

{| class="wikitable" style="width:70%"
|-
! Command !! Description
|-
| Reset Windows '''F5''' || Moves all floating UI windows to their default
positions.
|-
| Fullscreen '''F11''' || Makes the application fullscreen, or
windowed if already fullscreen.
|}

==== Help Commands ====

{| class="wikitable" style="width:70%"
|-
! Command !! Description
|-
| Changelog... || Opens up the Changelog window.
|-
| About... || Displays Copyright Information, Program
License, and Revision #.
|}

==== Viewport Controls ====

{| class="wikitable" style="width:70%"
|-
! Command !! Description
|-
| Drag Viewport '''MMB'''|| Drags the viewport relative to cursor
movement.
|-
| Adjust Viewport ← → ↑ ↓ / '''Arrow Keys'''|| Moves the viewport one tile distance in the
direction pressed regardless of zoom level.
|-
| Zoom Viewport '''Scroll Up / Down, Ctrl + +,
Ctrl + -'''|| Zooms the viewport in or out relative to the
tile closest to the cursor. There are 14 zoom levels.
|}

==== Mapping Hotkeys ====

{| class="wikitable" style="width:70%"
|-
! Command !! Description
|-
| Place Object '''LMB''' || Places the Active Object on the tile beneath
the cursor. The Active Object will be placed
above all other existing objects of its type. If
the Active Object is a turf, it will replace the
current turf on the tile.
|-
| Delete Topmost Object '''Ctrl + LMB'''|| Deletes the top most object on the clicked
turf.

'''Note''': Only deletes objects from enabled
layers.
|-
| Make Active Object '''Shift + LMB'''|| Makes the currently highlighted object the
Active Object. Only works on enabled layers.

'''Note''': StrongDMM uses the term Active
Object and Selected Object interchangeably.
This guide will use the term Active Object for
all instances of Selected Object for clarity’s
sake.
|-
| Quick Edit Menu '''RMB''' || Brings up a menu containing most all of the
Edit Commands. This menu also contains all
objects on the clicked turf, including one’s on
disabled layers. You can edit objects from
here as well.
|-
| Edit Object '''Shift + RMB''' || Opens up the variables window of the
highlighted object.

'''Note''': All edits made to variables generate
new instances, even if all edits were made at
the same time! Unused instances are cleared
when the map is saved. Don’t worry about
making extras.
|-
| Delete Object '''Ctrl + Shift + LMB''' || Deletes the highlighted object.
|-
| Replace with Active Object '''Ctrl + Shift + RMB''' || Replaces the highlighted object with the
Active Object.

'''Note''': This command, in-editor is called
Replace with Selected Object.
|-
| Reset To Default || Resets the clicked object to its most basic
form, removing all instance edits.

'''Note''': Only available through the Quick Edit Menu.
|-
| Tile Mode '''1'''|| Changes placement mode to single tile.

'''Note''': This is the closest you’ll get to a brush
tool in StrongDMM.
|-
| Fill Mode '''2'''|| Changes placement mode to square
selections using '''LMB + Drag'''.
|-
| Selection Mode '''3'''|| Changes mode to Selection only.

'''Note''': Selection Mode has its own unique
mouse behaviors, listed below.
|-
| Select Area '''LMB + Drag'''|| Selects a square area relative to the initial
click, and where the cursor is dragged. The
selection will be highlighted and given a
green border.

'''Note''': Only selects objects from enabled
layers.
|-
| Move Area '''LMB + Drag'''|| Moves the selected area relative to the
cursor, overwriting tile contents when '''LMB''' is
released, and leaving blank space where the
original selection was made.
|-
| Edit Direction / Dir Slider|| Allows manipulation of an object’s cardinal
direction in the form of a slider, creating an
instance if required.

'''Note''': Only available through the Quick Edit
Menu. Can also be done through Variable
Edits.
|-
| Nudge X/Y-Axis || Allows manipulation of an object’s offset via
Step, or Pixel, from its origin on a tile,
creating an instance if required.

'''Note 1''': Only available through the Quick Edit
Menu. Can also be done through Variable
Edits.

'''Note 2''': Never, ever edit Step_X or Step_Y.
The default nudge type can be set in the
Preferences window.
|-
| Move To Top / Bottom || Sends an object to the top, or bottom, in
terms of Byond sorting, of the same type.
'''Note''': Only available through the Quick Edit
Menu.
|}

==== Instance Commands ====

{| class="wikitable" style="width:70%"
|-
! Command !! Description
|-
| Find Instance On Map || Brings up the instance locator menu, as well
as the search results. The instance locator
menu can be used to locate instances
identical to the one you’ve got selected.

'''Note''': You’ll need to manually define the
search rectangle though, as it’ll default to the
single tile you have selected.
|-
| Find Object On Map || Brings up the instance locator menu, as well
as the search results. Instead of having an
instance ID entered by default, the typepath
of the selected object will be searchable
instead.
|-
| New Instance... || Opens up a variable editing window. Any
changes made to this window will generate a
new instance in the instance viewer window
for use later.

'''Note''': Instances not placed on a map will be
deleted upon the next load, and will have to
be made again if you wish to use them.
|-
| Generate Instances from Icon-States || Makes instances of the active object out of all
other valid icon-states within the icon file the
active object is derived from.
|-
| Generate Instances from Directions || Makes instances of the active object out of
any valid directional icons stored within its
original icon-state.
|}

== Key Mapping Terms ==
'''Tile''': Byond maps are giant grids. Each grid mark is a tile. Tiles always contain a space turf, this
is as empty as a tile can get.

'''Active Object''': The object currently selected / active. This is the object you’ll be placing down
when you click. The object will be viewable in the Environment Tree to the left, and highlighted.
If you have an instance selected, it will be highlighted in the instance window below.

'''Area(s)''': Areas are part of how Byond handles maps, and for CM13 it’s how we determine what
portions of the map are valid for fire missions, what does, and does not require power (and thusAPCs), where resin, tunnels, Xeno Structures, Marine Structures, and other things are allowed
or disallowed. Areas are never drawn in game. Anywhere without an area will not have lighting,
and will kill any mob that enters it, just very very slowly. Areas are like the nervous system of a
map. Without it, maps just don’t function.

'''Turf(s)''': Turfs are the walls, and the floors that make up the world. There can only be one turf
per tile. If you’ve managed to get two on one, you’ve made a big mistake. Turfs are like the
skeleton of a map.

'''Auto-Turf(s)''': Floor turfs that dynamically place borders around them when the map loads, or
when they take damage in game. They look nice, but can get expensive when used en-masse.
If your map’s tileset is primarily made of Auto-Turfs (Ice Colony and Kutjevo are good examples
of this), make sure to be sparing on the Decals and other objects.

'''Open (Turf)''': Turfs that aren’t walls. Mobs can move through these.

'''Closed (Turf)''': Turfs that are walls. Mobs cannot move through these.

'''Invisible Wall Blocker''': A type of Object (see below) that acts like an indestructible Closed turf.
Used to deny access to areas that are out of bounds, but composed of Open turfs.
Reinforced Wall: Walls that are destructible, but require extra effort to punch through. They can
only be melted by higher tier Aliens, and stronger explosives (they may need multiple to break).

'''Hull''': Walls that are indestructible. Usually denoted in-editor with a different icon. Often the
subtype of another wall type.

'''Mob(s)''': These are Aliens, Humans, and NPC mobs. Mobs are divided into two categories,
Carbons, and Simples. Carbons are complex and simulated, while Simples aren’t. For Example,
Humans and Aliens are Carbon mobs, while Jones and AI Aliens are Simple mobs. Mobs have
no comparative bodily analogy, sorry.

'''Map Sorting Layers''': In StrongDMM, what is, and isn’t enabled in the viewport is referred to as
a ‘Layer’, which can be sorted. This isn’t wholly accurate, but it is the term that gets used.
Sorting Layers are NOT the same as Byond sorting, or CM13’s Object Layers.
var/layer: This is the CM13 Object Layer, which is used to determine visual hierarchy in terms
of drawing objects on a tile. Take note, this variable can be edited, though some map instances
are overwritten upon server initialization, so it doesn’t always work!

'''Top / Bottom''': When numerous objects of the same type are on the same visual layer (not to be
confused with map sorting layers), some will appear above others and obscure them, this is
determined by what is on Top, and what is on Bottom. This is what we’ve been referring to asByond Sorting. Since Byond isn’t 3D, Z-fighting isn’t possible, though if that could happen, this is
what would prevent it. You usually don’t need to mess around with this at all. Players may also
bring objects to the Top, or Bottom ingame.

'''Object(s)''': These are guns, clothing, windows, window frames, and pretty much everything else
that isn’t a wall or floor. Everything you can interact with (save for mobs), are objects. Objects
are the meat of a map.

'''Effect''': A subtype of Objects, these are a whole host of things, from the holes Aliens melt in
walls and the acid that gets vomited on items, to the sparks that come off of explosions. You
shouldn’t be manually placing these unless they’re Decals or Landmarks.

'''Landmarks''': A subtype of Effects, these are map objects that do something when the server
loads the map, or function as a saved set of coordinates for a specific event (like the CORSAT
teleporter). You’ll mostly be placing these as spawn points for various factions, and not much
else save for a few other cases.

'''Decals''': A subtype of Effects, these are non-interactable details on maps. Blood is the most
common decal. Fun fact: The catwalks on Sorokyne Strata are also decals. Decals get
expensive when placed en-masse, so try to be sparse with them
.

''Item'': A subtype of Objects, these are all the things you, as a player can pick up, ranging from
clothing and guns to cigarettes and unplanted Alien eggs.

'''Structures''': A subtype of Objects, these include pretty much anything static (with some
exceptions) on a map. Some examples include: chairs, lockers, windows, window frames,
platforms, tall grass bushes, and potted plants.

'''Machines / Machinery''': Machines, a subtype of Structures, are objects (mostly static) that have
some sort of interaction with other objects. For example, Thermal Generators, APCs, wall lights
are machines. All atmospheric objects are machines, but they have their own terminology.

'''Pipe''': This is what a single pipe object is referred to in terms of Atmospherics.

'''Piping''': This is what two or more pipe objects that are connected, are referred to in terms of
Atmospherics. Note: This term should not be confused with the Pipeline, which more
importantly, refers to the process by which Gitlab, CM13’s code hosting service determines if a
Merge Request has no compilation conflicts, and passes all supplied unit tests. This is known as
“Pipeline Passing”.

'''Pipe Machine''': This is what one unconnected vent, scrubber, valve, cooler, port, etc, is referred
to in terms of Atmospherics. Anything that isn’t a regular pipe, but can connect to pipes, is a
pipe machine.Pipenet: This is what when one or more pipes are connected to pipe machines are referred to
as in terms of Atmospherics. Xenos may freely traverse completed pipenets that have valid
entrances and exits (Vents and or Scrubbers).

'''Powernet''': This is the abstract power supply available from all active generators (Thermal /
Portable) available on a single Z level. Powernets are localized entirely to their Z Level.
PSU (Power Storage Unit / SMES): This object allows one to meter the power leaving the
Powernet into machines, while also viewing total available power within the powernet. You need
to place at least one per Z, preferably near a Generator.

'''Generator''': Usually refers to a G-11 Thermal Generator map object, which when repaired puts
power into the Powernet for use by PSUs and APCs. You need to place at least one per Z,
preferably near a PSU and an APC.

'''APC (Area Power Controller)''': This object allows players to control the interaction between the
Powernet, and Machines in the local Area (see above) the APC is placed within.
Spawner: A general term that refers to something (usually a landmark) that makes something
on map load, and then deletes itself.

'''Detailing''': Refers to the aesthetic qualities of a map, or area in terms of objects, unique turfs,
and other aesthetic sensibilities, such as color palette, and visual design.
Detail Density: An aesthetic term that describes how detailed one area is vs another, as
determined by the amount of objects, unique turfs, and others. It can also be used as a broad
term to refer to a map as a whole in reference to total detailing, and potentially, performance
deficits.

'''.DMM (Dreammaker Map)''': The file format that Byond maps are stored in. They’re actually
plaintext, and can be opened with Notepad, or a code editor of choice.

'''TGM (TG Map)''': TGM is a .DMM format. It stores information in a far more humanly readable
way, and also allows for Git Conflicts to be resolved in a far less messy manner. Map Merge 2
converts Byond Maps to TGM. TGM is not an extension type.

'''Map Merge 2''': A python tool that converts Byond maps to TGM format, while also resolving
conflicts between versions, if any are found.

'''Dictionary Key (Dict-Key)''': Byond stores map information in what are called Dictionary keys
(dict-keys for short), which are a sequence of three letter characters contained at the bottom of
the map file in a sequence. Dict-keys are first defined when a new combination of area, turf,object, and mob are placed on a tile. If this specific combination is ever reused, instead of
defining those lines again (Byond maps are plaintext), the existing Dict-Key is used instead.

'''Corruption''': Your map got done fucked up son. This happens in pretty much any Byond map
editor. The Save As function is notorious for corruptions. Make sure to utilize Git Version control
to ward away the setbacks of a map corruption.

'''Dictionary Corruption''': Your map’s Dict-Keys have somehow been scrambled or altered.
Depending on the extent of corruption, can, or cannot be fixed by hand. These are easy to spot
when the Area Layer is enabled.

'''Variable Edit (Var-Edit)''': Usually refers to the act of editing the variables of an object (the
information stored within it) in game. However you can also do this in-editor, which leads to
instancing.

'''Instancing''': The creation of variants of an object that differentiate from the original because of
edited or alternative variables. These child objects are called Instances.

'''Instance''': An object that has different variables than it’s base definition. Not to be confused with
a Child Object in terms of Object Oriented Programming.

'''Typepath''': The path of an object in-game and in-editor. Objects further down the typepath are
Child Objects.

'''Environment Tree''': This is the set of nested dropdowns of objects, and a visual representation
of typepaths within the code. Get used to navigating it quickly and efficiently, as that is key to
successful and intuitive mapping.

'''DME (Dream Maker Executable)''': The compiled game binary, used to run servers, and read by
map editors to know what objects can be placed in maps.

'''Map Window''': The tab/window in which a map is currently open. One map window per map.
Viewport: The actual visuals within the Map Window, these two terms will likely get used
interchangeable in conversation with maintainers, and this guide.

'''.DMI (Dreammaker Image)''': PNGs wrapped up in a different file format. These contain all the
sprites in the game. In the code, DMI files are called as var/Icon.

'''Icon''': This is the actual file in which an Icon-State is stored. Icons are typically .DMI filesIcon-State: This is a specific ‘state’ within an Icon. To check what states are valid, you can
open the DMI, or have StrongDMM generate instances based on Icon-States in the instance
context menu.

'''Tile Set''': A specific set of icons, and code, that combine to create a thematically grouped
collection of floors and walls. CORSAT, Sorokyne, Prison Station, and Solaris Ridge all have
their own unique Tile Sets.

'''Tile/Object Palette''': An analog to the art term, palette, your object (or tile) palette is the
collection of frequently used tiles (and objects) that make up your map. Distinct from a Tile Set,
in that it’s defined by frequent usage, and not necessarily consistency. For example, water tiles
and atmospheric pipes are both part of your map’s palette, but aren’t part of a tile set.

= Part 1: Using the Editor =
== Introduction ==
If you’re starting here and haven’t read anything yet, make sure you go read the disclaimer at
the top, please, seriously. You won’t get anywhere without making sure you’re following what’s
said there first.

For this guide we’ll be using StrongDMM, which is an alternative editor to Byond’s included Map
Editor (sometimes referred to as BaseDMM). The reason we’ll be using StrongDMM is because
it is more user friendly, (generally) has better performance, and most importantly, saves natively
in TGM.

Part 1 will walk you through it all, from opening maps and making your first edits to creating
instances in baby steps. If you’re already experienced with mapping software, or don’t want your
hand held by a document and its contents, you can probably safely skip over to Part 2: Mapping
Theory, and make use of the StrongDMM Reference when you need it.

=== 1. Setting up StrongDMM ===
Before we can get started, we need to configure StrongDMM for CM13. Navigate to the File tab,
open it up, and click Preferences…
Make sure to set the Map Save Format drop down to TGM.
Make sure Sanitize Variables and Clean Unused Keys are also both enabled.
Lastly, ensure that Nudge Mode is set to pixel_x/pixel_y. Having this option set to
step_x/step_y will break smooth movement in-game, and we don’t want that.After that’s all set, feel free to fiddle with the settings to your liking.
When you’re ready to continue, X out of the menu.

=== 2. Navigating Maps ===
To start things off, let's open your compiled CM13 DME file (if you don’t know how to do that,
check out the guide [[Guide to Git|here]]). Navigate to the '''File''' tab, and hit '''Open
Environment…''' Once the loading bar at the top of the screen disappears, you should see a
now populated Environment Tree to the left, and a blank screen. Double check in the upper left,
it should read “ColonialMarinesALPHA - StrongDMM”.

From here, let’s open up a map file. Navigate to the '''File''' tab, and hit '''Open Map'''. This’ll open a
Windows Explorer window in the base of your local repository. Head into the '''Maps''' folder, and
select '''Z.01.LV624'''. You can open the map by hitting the '''Open''' button, or by double clicking.

[[File:MCC Fig1.jpg|left]]Your window should now look something like
the left. Those funny colors and tiles that say
‘SW’ over them is the '''Areas Layer'''. In CM13,
'''Areas''' are used to control what places need
power, allow or disallow certain activities,
such as construction or tunneling, and also
what places can accept fire missions or CAS
lasers. For now, we don’t need to pay
attention to ''Areas''. They can be safely
toggled off by hitting '''Ctrl + 1 (Toggle Area Layer)'''.

You might (or might now) see some white outlines around and at the borders of where Areas
met. These borders will persist even when the Areas layer is disabled. If you find them
distracting, you can disable them going to the '''Options''' tab, and unchecking '''Frame Areas'''.

There’s still a lot going on in our viewport, but before we can dive into what’s going on, let’s get
used to navigating the map, and using viewport controls to get around.

First, let’s use MMB (Middle Mouse Button) to pan around the map. Click in the MMB, and
release to stop panning. You’ll notice the editor slows down while panning quickly, or when
panning over areas with lots of objects. This is completely normal, even for more robust
hardware setups.

You can also Scroll up or down with your mouse wheel (or track pad, gesture commands that
emulate scrolling also work) to zoom in and out of the viewport. Note, that when you zoom, it all happens relative to where your cursor is, and more specifically, which tile it is hovering over. You’ll pan further when zoomed out more.

Panning and zooming are the primary forms of navigating maps in StrongDMM.

If you’d like to make a more precise viewport adjustment, the arrow keys allow you to move the
viewport by one tile in the cardinal direction you just pressed. This movement is relative to the
current viewports positions, and won’t snap the viewport to be turf accurate, it’ll only move the
viewport the distance of one turf at the current zoom level. There are 14 total zoom levels.

=== Basic Editing ===
Now that you’re comfy with moving around the map, we’re going to cover barebones editing
controls. Navigate up to LV River, just north of Hydroponics.

For reference, in Byond mapping:

Up - North

Right - East

Left - West

Down - South

Zoom in to the river, and press 2, to change your tile placement mode to Fill. Tile mode, which
can be activated with 1, can be useful, but we suggest you do the majority of your mapping on
Fill mode, it becomes far more intuitive the more you use it.

[[File:MCC Fig2.jpg|left]] Right now, you probably don’t have an Active Object, which is to say if you click,
nothing is going to be placed down. To change that, hold Shift, and then move
your cursor over one of the “strange trees”. It should highlight green. Left click to
make it the Active Object.

[[File:MCC Fig3.jpg|right]] Place a few in the river, and then their undo placement with Ctrl + Z (You can also redo with Shift + Ctrl + Z). If you click twice on a tile, even though it doesn’t look like it, two trees will have been placed down. To confirm this, right click the tile. From there, you can highlight the second tree and then delete it. You can fiddle with the Dir and Offset settings, but we won’t be covering those until later.

Place two trees in a row next to one another. Now, hold Ctrl, and drag a selection box around them. Ctrl + Drag, on Fill and Select Mode, deletes the topmost objects of the selected type on a tile. The selected type does NOT refer to the Active Object, rather only if you have an Area, Turf, Object, or Mob as the Active Object. Top most deletion is handy when you need to quickly clear an area of a lot of objects, but not all of them. The last placed object (usually) is the top most object on a tile.

Undo, or place two more trees down. Holding '''Ctrl + Shift''', click on one of them. It should highlight in red. This will delete the object. Deleting this way allows for deletion of any object, turf, mob, or area that’s currently visible. You have to be able to click it to delete it, so if it’s not
enabled per the Layers Filter, no dice.

Undo, or place two more trees down. Now, select a new object, such as some of the flowers, or
one of the reed bushes in the river and make it the Active Object. Go back to one of your trees,
and this time '''Ctrl + Shift + RMB''', instead of '''LMB'''. This will replace the tree with the Active
Object.

=== Copy, Cut, Paste ===

Copying, cutting, and pasting are tools that, if used effectively, can greatly speed up the
mapping process and cut down on the time spent combing the Environment Tree for the right
object. Combined with picking the Active Object from already placed ones, you might not even
have to use the environment tree at all.

Before we can copy, cut, or paste, we’re going to need to learn how to use the '''Selection Mode''',
which can be accessed by pressing '''3'''. Notably, you cannot change tile placement and selection
modes by using the Number Pad on an extended keyboard.

In Selection Mode, the mouse’s basic click functions follow special behaviors. Without any selection, you can LMB + Drag to make a new selection. Repeating the same action, '''LMB + Drag''' anywhere within the bounds of the selection will drag the selection relative to the mouse on the tile grid, replacing all content it’s floating over when you release the mouse. If you want to clear your selection, press Ctrl + D. When moving selections, the original tiles will be cleared. Only content on enabled layers will be selected and moved.

Copying, cutting, and pasting work exactly the same in regards to mouse controls. Notably,
when pasting a selection onto a map, the content will overwrite everything around it. Pastes
always are relative to the cursor, starting at their origin tile in the bottom left of the selection. If
you paste a selection while not in Selection Mode, you will not be able to manipulate it after
pasting, which can be frustrating. As such, make sure you do the most of your Cut, Copy, and
Paste while in Selection Mode ('''3''').

=== Instancing Objects ===
This segment covers the basics of instancing, and only the basics. Advanced instancing is
something you’ll encounter on a case by case basis, and it’s best to get live help than refer to a
guide for those cases.

Firstly, lets get familiar with the concept of instances. What are they, and why do we want to
use them?

An '''instance''' is a variant of an object that is different in any way from its original state. An
instance is NOT a child object further down the typepath.

Common instances include: renamed items and airlocks, changed item descriptions, APCs and
NanoMeds offset to appear on walls, and floor tile variants. Mapping without instances can be
done, but it requires a lot of extra code that isn’t needed. Why define a new child of an object
that only has a different name, when we can instance the name instead?

Instances are stored on a map by map basis, and are not shared between them. However,
StrongDMM is able to recognize instances between map windows if you have two or more
open, which can be useful in certain situations.

[[File:MCC fig4.jpg|left]] Reselect our friend the strange tree. Looking in the bottom left, you’ll spy there are already two instances of the strange tree being used on the map. This bottom left window is the instance viewer. Clicking either of the other instances will display the differing variables to the right of the initial window. You’ll notice the top most instance reads “Empty (instance with initial vars)”. When you
reset an object to default, it’s this topmost variant of itself that it will return to. Try placing any of
these instances.

Let’s make some more instances. Right click any of the three and hit '''Generate Instances from Icon-States…''' This should make a bunch new instances for us to screw around with. You can always hit '''New Instance…''' if you only want to make one more, though unless you know exactly what you’d like to make, it’s usually a safer bet to generate from icon-states or directions.

Be careful when generating instances! You’ll notice that a bunch have been made when we hit '''Generate Instances from Icon-States…''', maybe even too many. Some Icon files are very large, and have a lot of icon states shared between objects, turfs, and others. If you need to clear that list, close the map and re-open it. They should be gone when the map gets reloaded in the editor.

[[File:MCC fig5.jpg|right]] If you have a lot of instances that you are using you can add '''additional rows''' to the instance window by clicking on the cog icon (upper right of the window). Let’s cover automatic instancing. Moving south of the river, head over to the medical dome and make one of the folding metal chairs the Active Object. You’ll notice it already has instances of all its directions in the lower left. Moving down the Environment Tree, select the comfy child object. Right click the initial instance, and hit '''Generate Instances from Directions…''' Now we have all the cardinal directions of the comfy chair for our mapping leisure. Not all objects have directional variants. When in doubt, you’ll probably have to check the icon file itself. While we can’t open the Icon in StrongDMM (or any map editor for that matter), we can find it easily.

Place down one of the new comfy chair instances anywhere on the map, and right click it. You’ll notice in the right click menu we can see all objects, regardless if their layer is enabled or not. Moving the cursor over the comfy chair will give us some extra options to explore.

This right click menu is known as the Quick Edit Menu, and gives you access to Edit Commands as well as more specific object functions.

Your first set of options is the ability to '''Nudge'''. Nudging allows you to offset the object on its tile, without actually moving it from the tile to another. This can be useful for decorative purposes or for wall mounted machinery, like NanoMeds, or APCs. Play around with the two sliders, but make sure you’ve got Nudge set to Pixel Nudge in your Preferences.You’ll notice that with each release of the mouse from the nudge sliders will make a new instance of the object. Making just three nudges, makes three objects! Remember, you can clear unused instances by reloading the map file after saving.

Secondly you’ll notice the '''Dir''' (Direction) slider. This can be used to rotate your object in various cardinal directions. If the object has directional sprites in it’s icon-state, they’ll be automatically applied.

Under those two aesthetic adjusters, you’ll notice the '''Move To Top''', and '''Move To Bottom''' buttons. You can read about those in the Key Mapping Terms. You won’t really be using these.

Most importantly, we get to our two unfamiliar commands, Edit… (Shift + RMB) and Reset to
'''Default'''.

'''Reset to Default''' does exactly as it says, and restores the object to its original initial variable
state, or the top most instance of that object’s type.

'''Edit… (Shift + RMB)''' more importantly brings up the '''Variable Editing''' window ('''VarEdit''' shorthand). From here we can directly modify any variables associated to this object in the code. Before we get into anything in this window, make sure to tick the box next to '''By Type'''.
This’ll group variables by what typepath they’re associated with.

If you tick the '''Modified''' box, only the currently modified variables will appear. You’ll notice that Dir, and Nudge (pixel_x, pixel_y) are both variables. Anytime you change a single variable, a new instance is made.You can also filter variables (or search them, it’s the same function) at the top bar.

You can also filter variables (or search them, it’s the same function) at the top bar.

[[File:MCC fig6.jpg|right]] Finally, let’s figure out how to locate the actual icon file our comfy chair uses. Filter for, or look for the term “icon”. The resulting variable gives us the path to the icon file, you need only locate it in Windows Explorer now if you’d like to actually inspect the .dmi file.

For now, that’s all we’ll cover on variable editing. As said, you can edit everything via instancing, but you can’t change the direct code. In this case, if you wanted you could tell the comfy chair to find an entirely different icon file if you wanted to! Assuming of course you had the correct path punched in.

=== Common Variables ===
{| class="wikitable" style="width:70%"
|-
! Command !! Description
|-
| desc ||
The description of an object. If set to null, it will use the parent objects description. This variable must be enclosed in full quotes “”, otherwise your map won’t compile.

'''Note''': Smart quotes, and quotes, are not the same unicode character, and smart quotes will break your map file. StrongDMM never uses smart quotes, but a text editor you use might, so be careful if you’re pasting from an outside source.
|-
| name || The name of an object. If set to null, it will display an empty space in game. This variable must be enclosed in full quotes “”,
otherwise your map won’t compile.
|-
| req_access || Used by lockers and doors to determine what access is needed to open them. When set to null, no access is required.

'''Note''': A list of access numbers can be in the code file (someone get me the name & path)
|-
| Open Map… '''Ctrl + O''' || Opens any map on a local hard-disk.

'''Note:''' ''Opening a map will open a new map
window, and will not close any other open
map windows.''
|-
| req_one_access || Used by doors to determine if a single access number permits use opening. When set to null, no access is required
|-
| color || The tint of the object. Use RGB or Hex Color Codes. Null is the default; no tint. Works best on grey-scale sprites.
|-
| luminosity || The numeric intensity of how bright the object is in light calculations. Null means no light.
Can be given to objects that normally do not produce light, making them glow.
|-
| anchored || A true (1) or false (0) variable that determines if an object can move. Objects that can normally be picked up, cannot be so when anchored is set to true.
|-
| wrenchable || A true (1) or false (o) variable that determines if an object can be wrenched down to the ground, changing its anchor status.
|-
| density || A true (1) or false (0) variable that determines if an object is ‘dense’. Dense objects prevent passage through the tile they inhabit. Walls are dense objects, floor tiles are not.
|-
| health || The numeric health of an object. If set to null, it’ll use the parent value. When this reaches zero the object is destroyed or enters a damaged state. Varies per object type.
Objects that can be picked up (such as guns, or pillbottles) do not usually have health values.
|-
| unslashable || A true (1) or false (0) variable that disables slashing by Aliens. Only valid on structures, walls, and other objects with health values that are targettable by default.
|-
| climb_delay || A numeric value in terms of millisecond delay when climbing objects.
|-
| climbable|| A true (1) or false (0) variable that allows mobs to climb over, or onto the object in question. When null defaults to 0. May cause unintended behavior when set to true.
|-
| drag_delay|| A numeric value in terms of millisecond delay that is applied as a pause to mob movement after dragging an object. Calculated against a mob’s individual drag speed.
|-
| tag || A string variable that is sometimes used to flag certain aspects of an object or turf with additional information. Usage is deprecated in modern CM13, but it shows up occasionally.
|-
| icon|| The direct file path within the code to the .dmi the object searches in for icon_states. Can point towards any other dmi if the pathing is correct.
|-
| icon_state|| The name of the icon_state within the .dmi file specified by the icon variable. Will display the no name sprite (usually an error or invisible) within the .dmi if the specified icon_state is invalid.
|-
| pixel_x / pixel_y|| Integer offsets that change the origin of an object on a tile (default is at 16,16, the center of the tile, which in pixel_x/y is 0,0). Can be modified easily with the right click menu.
|-
| bound_height/width || Integer values, where 32 = 1 tile. When set larger than 32x32, a multi-tile object is created. Useful for large sprites, or
multi-sprite objects.
|-
| dir||The cardinal direction (stored as an integer) in which the object is facing. If the icon_state has dir variants, these will display accordingly. The directions are as follows:

1 - North

2 - South

4 - East

8 - West

5 - Northeast

6 - Southeast

9 - Northwest

10 - Southwest

'''Note''': 2 - South is the default dir value.
|-
| stuff || List variable that contains the potential contents of a largecrate/random object. Can be directly modified to have different contents if paths are correct.
|-
| start_charge || The % charge of an APC when it first spawns on map initialization. Should usually be left on defaults, or overridden to 0.
|-
| projectile_coverage|| The % chance a projectile has to hit the object in question when it passes through the tile it exists in.
|-
| flipped|| A true (1) or false (0) variable that determines if a table has been flipped or not. The flip direction is dependent on the dir variable.
|-
| frequency|| The frequency of headsets and intercoms. Defaults to 145.9 common channel. Custom frequencies must end in an odd number, otherwise they won’t work.
|}

= Part 2: Mapping Theory =

Hopefully by now you’ve gotten decently comfortable with StrongDMM and know your way in and around instances. If you’re not yet, I advise you head back to the previous section, make a few edits on existing maps and screw around with the various tools and items you have at your disposal. Getting comfortable with the tools themselves is half the battle when working with Byond.

This following section is about general CM-13 mapping theory. Remind yourself that CM-13 is a combat server, as such any theory you might have learned, or developed yourself from another SS13 server does not apply here, at all. Seriously, don’t go in trying to make an SS13 map, or editing an existing map to be more like one. It is a quick road to having your merge request turned down for violating the theories and ideas you’re about to read.

With that said, the following segments are not set in stone (save for the Basic Map Requirements), but we highly recommend you follow them to the best of your ability. As you become more experienced with mapping, and CM-13 in general, that same experience is your license into more experimental or non-traditional maps and inserts.

One last thing before we continue, while the following segment is loosely outlined around the thought process of making an entirely new map, understand that there is no specific order to map making once you’re past the drafting stage, and you, and everyone else, may, and will, approach the mapping process in a way that best suites their abilities. You should also note that we (the CM-13 development team) expect contributor-mappers to not go and make new maps

as their first project. We suggest, and would much prefer it if you made Nightmare Inserts (NMC, for short). You can read about what Nightmare Creator is here.

== Basic Map Requirements ==

A map built for the default gamemode Distress Signal can be boiled down to a few simple elements. Without these, the gamemode will not be able to run from start to finish properly.

* At least one Landing Zone
* An always powered indestructible dropship terminal placed next to each landing zone
* An area that permits the construction of marine structures; for telecomms.
* An area that permits the construction of alien structures; for the hivecore, spawning pool, and nest(s)
* X amount of small host spawners, where X is the map size in walkable tiles divided by 1000 and rounded down.
* One or more Hive Start landmarks; which allow the Queen to determine where to spawn the hivecore and herself at round start.
* 10, at the minimum, Survivor spawners.
* If your map uses the node income system; minimum one node spawner landmark and a node income controller object.
* If your map uses the legacy income system; a legacy income controller object.

'''''For a far more in depth break down of a Distress Signal map, you can check out this guide, written by TobiNerd, our Lead Mapper,'''''

It is highly advised that you have more than one (our recommendation is 3-5) Hive Start landmarks in order to allow the Alien team a degree of choice when starting the round in terms of their overall strategy in regards to map control and their base of operations.

There aren’t any hard rules on where one should place Landing Zones. Smaller maps, for ease of balancing and income node placement, prefer only one landing zone, while larger maps should usually have two in order to increase marine FOB options. If you have two landing zones on your map, they should both be equally spaced from the first income node that marines encounter. If one is closer, it will always get picked preferentially due to the timing advantage.
For more information on Landing Zones (and Hive placement), click here.

Small host spawners can be placed just about anywhere on the map, but it’s suggested that you place the most of them towards naturally occurring Alien territory. On most maps that do feature small hosts in thematic placement, they usually wind up in easily accessible containment cells grouped together in one place for ease of Alien team access. Small hosts should not be difficult to get, they provide pre-round activity for the Alien team, while also conferring a team resource.

Survivor spawns should be placed opposite of small host spawners; they should be closer to the LZ(s) than to potential Alien Hive Starts. Survivor spawns should also spawn next to or in a key location to allow ease of orientation. You can read more about Survivors [[Survivor|here]].

=== Layout, Chokepoint & Lanes ===
Lorem ipsum

=== Layout, Blockers ===
Lorem ipsum

=== Layout, Arenas ===
Lorem ipsum

=== Layout, Hives & LZs ===
Dropship terminals don’t have to be on or next to the landing zone directly like Sorokyne or LV, but they do need to be in an obvious place so that Queen players, new or old, do not get confused when attempting a hijack operation. CORSAT is a good example of non-traditional LZ computer placement, it’s in an office off to the side labelled flight control in clear view of the LZ.

=== Layout, Resource Nodes ===
Lorem ipsum

=== Pipes, as a hive-way ===
Lorem ipsum, bitch

=== Survivors, (and their Loot) ===
Lorem ipsum

=== Advanced Map Components ===
Lorem ipsum

=== Nightmare Creator ===
For the full guide on how to create nightmare inserts and how they work see:
https://github.com/cmss13-devs/cmss13/blob/master/maps/Nightmare/doc/Quickstart.md

'''What are Nightmare inserts:'''

Nightmare inserts are variations to different locations on the map that occur based on a random chance, The most common example is the fog on LV, By default the fog is full but nightmare inserts might create a hole in the fog.

'''Sprinkles vs Variations:'''

Variations are a group of nightmare inserts, usually regarding the same location. The nightmare insertion system will only pick '''one''' of the inserts in a variation group.

Sprinkles however are independent inserts that might or might not happen, however are not dependent on if other spawn.

'''How to create Nightmare inserts?:'''
* Open StrongDMM (SDMM) and choose a map and where you want to make a nightmare insert.
* Once you have chosen your desired area take the measurements.
* Create a new map file based on the measurements.
* On the new map file replace the areas of the insert with /area/noop_template and turfs you don't want with /turf/noop_template.
* Actually map in the insert.
* Save the insert with the following format: SpawnChance.InsertName.dmm (So if you want a 40% spawn chance you put 40.InsertName.dmm).
* Put the .dmm file inside the sprinkles folder of the map you want it for.
* Put a /obj/effect/landmark/nightmare in the bottom left corner of your original measurements on your chosen map. The landmark represents the bottom left part of your insert so if it is in the wrong place, your insert will spawn wrong.
* Change the landmark's insert_tag to your insert's name (If your insert is named 10.EasternGap.dmm, Your insert tag would be EasternGap)
* That's it!

== Part 3: Map Detailing ==

=== Using the Zoo ===
Lorem ipsum

=== Theming ===
Lorem ipsum, bitch

=== Detail Density ===
Lorem ipsum, bitch

=== Environmental Storytelling ===
Lorem ipsum, bitch

=== Custom Assets ===
Lorem ipsum, bitch

=== Getting Creative... ===
Lorem ipsum, bitch

= Frequent Questions & Mistakes =

Guide to Git

2024-12-05T06:45:00Z

Drulikar: Added mention of disabling actions when making a fork.

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Downloading Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

You will also likely want to disable actions running on your fork:

[[File:Fork Actions Settings.png|alt=You can disable actions from running on your fork by going to settings, general under actions, disable actions, and save.|frameless|655x655px]]

=== Step 3: Download Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of https://github.com/[YOURUSERNAME]/cmss13. Select a folder to download the repo into, and let it run. It may take awhile.

=== Step 4: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

Also - search for and install GitLens. It makes using the source control features of Visual Studio Code much easier.

[[File:recommended_extensions.png|400px]]

=== Step 5: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* Add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

NOTE: As of writing, BYOND 515.1633+ is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3).
[[File:Language Client Settings.png|655x655px]]

=== Step 6: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

=== Step 4: Setting up Git to Commit ===
In order to be able to commit changes, Git needs to know who you are. This requires an email and a username - in most cases, your username should be the same as your GitHub username. The email address can be either an email you're okay with people knowing - or the private email provided by GitHub. This can be obtained at [https://github.com/settings/email https://github.com/settings/emails] under the "Keep my email address private" setting.

Then, you need to open a new Terminal window inside Visual Studio Code. Using the top bar, navigate to 'Terminal' and 'New Terminal'. A window should appear at the bottom of your screen, containing a command line interface. Run the following commands:<pre>
git config --global user.email "your@email.here"
git config --global user.name "yourusernamehere"
</pre>

=== Step 5: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You can give it a commit message on the box with “Message”, and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 6: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your branch will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

File:Fork Actions Settings.png

2024-12-05T06:40:57Z

Drulikar:

How to disable actions from running on your fork.

File:Recommended extensions.png

2024-11-17T20:00:54Z

Drulikar: Drulikar uploaded a new version of File:Recommended extensions.png

File uploaded with MsUpload

Guide to Git

2024-06-21T22:08:59Z

Drulikar: Tweaked aux tools note on supported versions

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Downloading Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

=== Step 3: Download Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of https://github.com/[YOURUSERNAME]/cmss13. Select a folder to download the repo into, and let it run. It may take awhile.

=== Step 4: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

Also - search for and install GitLens. It makes using the source control features of Visual Studio Code much easier.

[[File:recommended_extensions.png|400px]]

=== Step 5: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* Add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

NOTE: As of writing, BYOND 515.1633+ is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3).
[[File:Language Client Settings.png|655x655px]]

=== Step 6: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

=== Step 4: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You can give it a commit message on the box with “Message”, and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 5: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your branch will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

Chemistry

2024-04-21T01:12:22Z

Drulikar: fix impedrezene anchor

----

{{Header
|PrimaryColor = #C90000
|HeaderContent = OOC Note
|SubContent = Only [[Doctor|Doctors]], [[Researcher|Researchers]], [[Nurse|Nurses]] and the [[Chief Medical Officer|CMO]] should be messing with chemical substances. [[Hospital Corpsman|Hospital Corpsmen]] should be aware of overdose thresholds and medications that cause harm when mixed in a patient.
}}

=Tools of the Trade=
# '''Chem''' '''Dispenser''': If you were a marine, this would be your rifle. It dispenses the basic chemicals if a beaker is placed inside. Runs off battery charge which replenishes over time. Has several settings for dispensing chems (5 to 40 units). [[File:ChemLab.png|thumbnail|border|right|Chemistry Lab]]
# '''ChemMaster''': This machine is used to precisely control the amount of chemicals in a beaker, creating bottles and pills. Once a beaker is placed in, you can move desired amounts of it's contents to "buffer" by clicking on buttons present next to the name of the chemical. Clicking again while they're in "buffer" will flush them down disposals, aka they're lost forever. This setting can be changed by the button located between the beaker and buffer contents, just click it once to change to "transfer to beaker." A pill bottle can be inserted into the machine to automatically hold created pills. You can insert and empty beaker into the chem master and click "create bottle" several times to get a bunch of 60u containers for free. You can make Phoron pills and dissolve them in your Phoron beaker as the quickest way of removing it from advanced chems.
# '''Chemical Storage''': Chemical storage. It can hold beakers, bottles, pill bottles, pills, etc etc. Useful for not having your chems all over the floor, but people usually forget to check it when in need of something.
# '''Vendor''': Holds restockable vials of key reagents, and syringes for faster chemical synthesizing.
# '''Beakers''': Several empty beakers that can be used for various purposes, such as storing mixes for the cryo-cells.
# '''Grinder'''/'''Juicer''': This is used to extract chemicals out of many things. For your uses, it'll be mostly pills and food. Most commonly used for grinding solid Phoron for your Clonexadone and Peridaxon needs.
# '''Boxes of pill bottles''': Empty pill bottles to hold up to 16 pills per bottle.
# '''Dropper and 2 beakers of Cryoxadone'''

----

==Equipment==

{| class="wikitable"
|-
! Equipment !! Description
|-
| '''Beakers and Bottles''' ||
* Most basic tool of your trade. Right-clicking one can change it's transfer amount per click. Pills can be dissolved in beakers that already contain something. If you "use" one while holding it in hand, you will put a lid on it, preventing you from splashing it's contents by clicking on the floor by mistake.
* They come in bottle/small beaker - 60u, large beaker - 120u, and bluespace beaker - 300u.
|-
| '''Dropper''' ||
* Like beakers, can be right-clicked for transfer amount. Used for moving small amounts of chemicals between other containers.
|-
| '''Syringe''' ||
* Has two modes switched by "using" it - draw and inject. Hold 15u max, draw 5u per click. Can be used to take blood samples and inject them into mass spectometers for analysis. Using it on harm intent will instantly inject a random amount of the chemical inside while dealing minor brute damage and destroying the syringe. Injecting someone else takes a short time of both standing motionless.
|-
| '''Injector''' ||
* Default ones hold 15u max. Injectors with bigger capacity can be made at the medilathe in research. They can be filled at the centrifuge in research. Pre-loaded injectors cannot be filled with more than their initial amount, for example, a dexalin plus autoinjector can hold only 1u no matter how hard you try to refill it.
|-
| '''Pill''' ||
* 60u max. Takes some time to use on someone, like the syringe. There's also a tiny delay between swallowing a pill and its contents entering your bloodstream, but it's too little to matter. Can be dissolved in a beaker already containing a solution.
|-
| '''Pill Bottle''' ||
* Holds 16 pills max. Clicking on a tile with pills on it while holding the bottle will pick up all the pills scattered on it.
|-
| '''Hypospray''' ||
* Holds 30 units, and comes pre-loaded with tricordrazine. Can be drained and refilled with a syringe or unloaded and loaded with vial. Instantly injects 5u doses.
|-
| '''Syringe Case''' ||
* Holds three syringes/bottles/injectors.
|-
| '''Labellers and Pens'''
||
*Labels can be put on most things you can click on. Only one label may be applied to an item. Activate the labeller without entering a label to remove them.
*Pens replace the name of a chem-master bottle, so instead of bottle (Peridaxon) you get a Peridaxon bottle.
|}

----

=Chemical mixes=
Various common mixes of medical reagents are ordered by hospital corpsmen. '''All of these recipes assume that you are using a bluespace beaker.'''

{| class="wikitable"
|-
! Mix Name !! Vendor and Chem Dispenser !! Chem Dispenser
|-
| {{anchor|imialky}}[[#imialky|'''ImiAlky''' (10u, 5u)]]
Also known as '''IA'''. Results in 160u of Imidazoline and 80u of Alkysine.
Overdoses 30u for both reagents (3 pills).
Used for healing brain damage and eye damage.
||
*Add '''120u''' of Dylovene from the Chem Dispenser.
*Add '''40u''' Chlorine,
*Add '''40u''' Nitrogen,
*Add '''80u''' Carbon,
*Add '''80u''' Hydrogen

Split into 16 pills.<br>

Restock the used bottles back on the Vendor once you are done. This can be done by dragging the bottles in one hand onto the Vendor.
||
*Add '''40u''' Silicon, '''40u''' Nitrogen, '''40u''' Potassium to make '''120u''' of Dylovene,
*Add '''40u''' Chlorine,
*Add '''40u''' Nitrogen,
*Add '''80u''' Carbon,
*Add '''80u''' Hydrogen

Split into 16 pills.<br>
|-
| {{anchor|merabica}}[[#merabica|'''MeraBica''' (7.5u, 7.5u)]]
Also known as '''MB'''. Results in 120u of [[#Meralyne|Meralyne]] and 120u of [[Chemistry#bicaridine|Bicaridine]].<br>

Overdoses on 15u of [[#Meralyne|Meralyne]] and 30u of [[Chemistry#bicaridine|Bicaridine]] (2 and 3 pills respectively).

Rapidly heals Brute damage.
||
*Add '''160u''' Bicaridine,
*Add '''40u''' Water,
*Add '''40u''' Carbon

Split into 16 pills.<br><br>

Restock the used bottles back on the Vendor once you are done. This can be done by dragging the bottles in one hand onto the Vendor.
||
*Add '''160u''' Carbon,
*Add '''40u''' Water,
*Add '''30u''' Oxygen,
*Add '''30u''' Sugar

Remove '''20u''' Bicaridine using the ChemMaster to have '''120u''' of Bicaridine and '''120u''' Meralyne.

Split into 16 pills <br>
|-
| {{anchor|keloderm}}[[#keloderm|'''KeloDerm''' (7.5u, 7.5u)]]
Also known as '''KD'''. Results in 120u of [[Chemistry#kelotane|Kelotane]] and 120u of [[Chemistry#dermaline|Dermaline]].<br>

Overdoses on 30u of [[Chemistry#kelotane|Kelotane]] and 15u of [[Chemistry#dermaline|Dermaline]] (2 pills).

Rapidly heals burn damage.
||
*Add '''160u''' Kelotane,
*Add '''40u''' Oxygen,
*Add '''40u''' Phosphorus

Split into 16 pills.<br><br>

Restock the used bottles back on the Vendor once you are done. This can be done by dragging the bottles in one hand onto the Vendor.
||
*Add '''40u''' Carbon, Carbon, Silicon, Silicon, Oxygen, and Phosphorus.

Split into 16 pills.<br>
|-
| {{anchor|tribica}}[[#tribica|'''TriBica''' (15u, 15u)]]
Also known as '''TB'''. Results in 240u of [[Chemistry#bicaridine|Bicaridine]] and 240u of [[Chemistry#tricordrazine|Tricordrazine]]. <br>

Overdoses at 30u for both reagents (2 pills).

Heals brute damage at a moderate rate and also slowly heals burns and toxin damage.
||
* Add '''60u''' of Inaprovaline,
* Add '''120u''' Bicaridine,
* Add '''60u''' of Dylovene

Split into 8 pills.<br>

* Add '''60u''' of Inaprovaline,
* Add '''120u''' Bicaridine,
* Add '''60u''' of Dylovene

Split into 8 pills.<br>

Restock the used bottles back on the Vendor once you are done. This can be done by dragging the bottles in one hand onto the Vendor.
||
*Add '''40u''' Carbon, Sugar, Oxygen,
*Add '''30u''' Carbon, Carbon,
*Add '''20u''' Nitrogen, Potassium, Silicon

Split into 8 pills.<br>

*Add '''40u''' Carbon, Sugar, Oxygen,
*Add '''30u''' Carbon, Carbon,
*Add '''20u''' Nitrogen, Potassium, Silicon

Split into 8 pills.<br>
|-
| {{anchor|nitrogenwater}}[[#nitrogenwater|'''NitrogenWater''' (10u, 10u)]]
More commonly referred to as '''NW'''. Helps deal with [[Chemistry#tramadol|Tramadol]] overdoses by reacting with in the body to create [[Chemistry#paracetamol|Paracetamol]], which has a higher overdose threshold of '''60u''' compared to [[Chemistry#tramadol|Tramadol's]] '''30u'''.
<br>
Tramadol overdose '''neutralizer'''. Does '''not''' fix toxin damage caused by the overdose.
<br>
This medical reagent has '''no overdose threshold'''. It should however be noted that [[Chemistry#tramadol|Tramadol]] and [[Chemistry#paracetamol|Paracetamol]] are toxic when mixed together. It is advised to double-check the patient for high levels of tramadol before using '''NW'''.
<br>
|| N/A
||
*Add '''40u''' of Nitrogen,
*Add '''40u''' of Water

Split into 4. <br>
|-
| {{anchor|fe}}[[#fe|'''Iron''' (15u)]]
Also known as it's chemical name of '''Fe'''. Adding [[Chemistry#sugar|Sugar]] to the mixture does not help restore more blood. [[Chemistry#sugar|Sugar]] is nutritious to an extent (NTR 1) but not Hemogenic. Results in 240u of [[Chemistry#iron|Iron]]. <br>

Overdoses at '''30u'''. <br>

Hemogenic level 3 (HMG 3). Restores lost blood faster.
||
N/A
||
*Add '''240u''' of [[Chemistry#iron|Iron]]

Split into 16 pills. <br>
|-
|
{{anchor|ironsugar}}[[#ironsugar|'''IronSugar (7.5u, 7.5u)''']]
<br>
Also known as '''IS'''. An objectively less effective version of just Iron. Results in '''120u''' of Sugar and '''120u''' of Iron.

Overdoses at '''30u''' due to the Iron being present in the reagent. <br>
<br>
||
N/A
||
*Add '''120u''' of Iron,
*Add '''120u''' of Sugar

Split to 16. <br>
|-
| {{anchor|atd}}[[#atd|'''AriTricaDylo''' (5u, 5u, 5u)]]
Also known as '''ATD'''. Results in '''80u''' of [[Chemistry#arithrazine|Arithrazine]], '''80u''' of [[Chemistry#dylovene|Dylovene]], and '''80u''' of [[Chemistry#tricordrazine|Tricordrazine]]. <br>

Overdoses at '''15u''' of [[Chemistry#arithrazine|Arithrazine]], '''30u''' of both [[Chemistry#dylovene|Dylovene]] and [[Chemistry#tricordrazine|Tricordrazine]]. (3 and 4 pills respectively).

Potent Toxin damage healer.
||
*Add '''40u''' Inaprovaline,
*Add '''40u''' Phosphorous,
*Add '''180u''' Dylovene.

Remove '''20u''' of [[Chemistry#dylovene|Dylovene]] to make '''80u''' of [[Chemistry#arithrazine|Arithrazine]], '''80u''' of [[Chemistry#dylovene|Dylovene]], and '''80u''' of [[Chemistry#tricordrazine|Tricordrazine]]
Split into 16 pills. <br>
||
*Add '''15u''' Carbon, '''15u''' Oxygen, '''20u''' Sugar to make '''45u''' of Inaprovaline,
*Add '''55u''' Silicon, '''55u''' Nitrogen, '''55u''' Potassium to make '''165u''' of Dylovene,
*Add '''40u''' Phosphorous.
'''NOTE: Very important you do these in the exact order.

Remove '''5u''' Sugar using the ChemMaster to have 80u of [[Chemistry#arithrazine|Arithrazine]], 80u of [[Chemistry#dylovene|Dylovene]], and 80u of [[Chemistry#tricordrazine|Tricordrazine]].

Split into 16 pills.<br>
|-
| {{anchor|dexplus}}[[#dexplus|'''Dexalin Plus''' (7.5u)]]
Also known as '''Dex+'''. Results in '''120u''' of [[Chemistry#dexalinplus|Dexalin Plus]].
<br>
Overdoses on 15u of [[Chemistry#dexalinplus|Dexalin Plus]].
<br>
Dexalin Plus instantly removes any initial oxygen damage.<br>
||
*Add '''40u''' Dexalin,
*Add '''40u''' Carbon,
*Add '''40u''' Iron

Split into 16 pills.
||
*Add '''23u''' of Phoron (grind a bar up and use a dropper)
*Add '''40u''' Oxygen, Oxygen,
*Add '''40u''' Carbon, Iron

To fill up a bottle of Dex+, split ONLY the 120u of Dex+ into 16 pills.<br>
*Add '''40u''' Oxygen, Oxygen,
*Add '''40u''' Carbon, Iron

Repeat the above step 3 more times.

|-
|}

{| class="wikitable"
|-
! Description !! Bottle !! Tank + Bottle
|-
| '''UNGA'''

UNGA is a mix of commonly used medicines combined into one substance: "UNGA juice". The final product should be pink once everything is mixed in. '''UNGA should only be bottled (60u), do not make UNGA pills.'''
||
OD limits depend on the chemicals in contained in the UNGA juice. The OD limit for this version of UNGA will be '''15u''' due to containing Dermaline. It is recommended to add all the medicines in the Bluespace beaker first, then remove certain amounts in the ChemMaster so that every chemical is 12u. This is used to make a full bottle (60u) containing equal proportions.

*Add '''12u''' Tricordrazine,
*Add '''12u''' Bicaridine,
*Add '''12u''' Kelotane,
*Add '''12u''' Dermaline,
*Add '''12u''' Oxycodone,
*Add '''12u''' Meralyne
||Add the following to the tank:
*Add '''120u''' Bicaridine ,
*Add 120u Kelotane,
*Add 60u Inaprovaline,
*Add '''60u''' Dylovene,
*Add '''120u''' Oxycodone
Add the following to a beaker:

* Add 40u Bicaridine,
* Add 40u Kelotane,
* Add 40u Carbon, Water,
* Add 40u Oxygen, Phosphorus

Add the beaker's contents to the tank.
|-
|}

=Chemicals=
The amount of a certain chemical in a marine's blood decreases by its '''metabolism''' value every life tick. Life ticks happen once every 2 seconds. The "effect" column contains the chemical's effects per tick unless stated otherwise.
The ratio column indicates how much of the chem you get when mixing. For example, a chem with a ratio of 4:4 takes 4 units of its component chemicals to make 4 units of the chemical itself.
Chems marked with '''(CATALYST)''' are not expended during the reaction.
The "OD" column for some chemicals has two numbers. The first is the threshold for the "normal" OD, the second is for critical OD. The next column "OD effects" contains the consequences of overdosing on this reagent. '''(C)''' indicates the effect of a critical overdose.

Cocktails and drinks can be found [[Drinks|here]].

==Basic==
Most of these chemicals have little use outside of making more complex ones and can be acquired while on the Almayer from chemical dispensers or via other means.
{| class="wikitable unsortable" style="width: 100%;"
! style="width: 10%; margin: auto;" |Name
! style="width: 20%; margin: auto;" |Effect
! style="width: 12%; margin: auto;" |Properties
! style="margin: auto;" |Acquiring
! style="width: 5%; margin: auto;" |Ratio
! style="width: 5%; margin: auto;" |Meta- bolism
! style="width: 5%; margin: auto;" |OD
! style="width: 20%; margin: auto;" |OD effects
|-
|{{anchor|water}}[[#water|Water]]
|
* Gets things wet.
* Extinguishes fires.
* Explodes when mixed with [[#potassium|potassium]].
|N/A
|
{{:Chemical/Water}}
|3:1
|0,01
|N/A
|N/A

|-
|{{anchor|ethanol}}[[#ethanol|Ethanol]]
|
* Basic alcohol type. [[Drinks#Alcoholic|All other ones]] are a subtype of this.
* Gets you drunk.
* Can be used to remove ink from paper.
|
* [[Researcher#ALH|ALH]] 4
* [[Researcher#FUL|FUL]] 3
* [[Researcher#OXI|OXI]] 3
* [[Researcher#FLW|FLW]] 2
|
{{:Chemical/Ethanol}}
|N/A
|0,2
|N/A
|N/A
|-
|{{anchor|oxygen}}[[#oxygen|Oxygen]]
|
* Fire.
|N/A
|
{{:Chemical/Oxygen}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|copper}}[[#copper|Copper]]
|
* Green fire coloring
|N/A
|
{{:Chemical/Copper}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|nitrogen}}[[#nitrogen|Nitrogen]]
|N/A
|N/A
|
{{:Chemical/Nitrogen}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|hydrogen}}[[#hydrogen|Hydrogen]]
|
* Explosives
|N/A
|
{{:Chemical/Hydrogen}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|potassium}}[[#potassium|Potassium]]
|
* Explodes when mixed with water.
|N/A
|
{{:Chemical/Potassium}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|mercury}}[[#mercury|Mercury]]
|
* Deals 4 brain damage per tick
|
* [[Researcher#NRT|NRT]] 4
|
{{:Chemical/Mercury}}
|N/A
|0,2
|30
|
* Deals 10 brain damage per tick
* Makes you jittery
* Makes you drowsy
|-
|{{anchor|sulfur}}[[#sulfur|Sulfur]]
|N/A
|N/A
|
{{:Chemical/Sulphur}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|carbon}}[[#carbon|Carbon]]
|
* Chemfire modifier
|N/A
|
{{:Chemical/Carbon}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|chlorine}}[[#chlorine|Chlorine]]
|
* Deals 0.5 brute damage per tick
|
* [[Researcher#BCD|BCD]] 1
|
{{:Chemical/Chlorine}}
|N/A
|0,2
|
* 30
* 50
|
* Deals 1.5 brute damage per tick
* '''(C)''' Deals 4 brute damage per tick
|-
|{{anchor|fluorine}}[[#fluorine|Fluorine]]
|
* Deals 0.5 toxin damage per tick
|
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Flourine}}
|N/A
|0,2
|
* 30
* 50
|
* Deals 1.5 toxin damage per tick
* '''(C)''' Deals 4 toxin damage per tick
|-
|{{anchor|sodium}}[[#sodium|Sodium]]
|N/A
|N/A
|
{{:Chemical/Sodium}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|phosphorus}}[[#phosphorus|Phosphorus]]
|
* Fire modifier
|N/A
|
{{:Chemical/Phosphorus}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|lithium}}[[#lithium|Lithium]]
|
* Fire modifier
* Makes you less confused and sends messages in chat.
|
* [[Researcher#OXI|OXI]] 1
* [[Researcher#PST|PST]] 1
|
{{:Chemical/Lithium}}
|N/A
|0,2
|
* 30
* 50
|
* Deals 0.5 brain damage per tick
* '''(C)''' Deals 3 brain damage per tick
* '''(C)''' Makes you hallucinate
|-
|{{anchor|nutriment}}[[#nutriment|Nutriment]]
|
* Nutritious. Helps restore lost blood.
|
* [[#NTR|NTR]] 1
|
{{:Chemical/Nutriment}}
|N/A
|0,2
|N/A
|N/A
|-
|-
|{{anchor|sugar}}[[#sugar|Sugar]]
|
* Nutritious. Helps restore lost blood.
|
* [[#NTR|NTR]] 1
|
{{:Chemical/Sugar}}
|N/A
|0,2
|N/A
|N/A
|-
|{{anchor|iron}}[[#iron|Iron]]
|
* Turns nutrition into blood.
|
* [[Researcher#HMG|HMG]] 3
|
{{:Chemical/Iron}}
|N/A
|0,2
|
* 30
* 50
|
* Deals 1.5 toxin damage per tick
* '''(C)''' Makes you really hungry
|-
|{{anchor|gold}}[[#gold|Gold]]
|N/A
|N/A
|
{{:Chemical/Gold}}
|N/A
|0,2
|N/A
|N/A
|-
|{{anchor|silver}}[[#silver|Silver]]
|N/A
|N/A
|
{{:Chemical/Silver}}
|N/A
|0,2
|N/A
|N/A
|-
|{{anchor|uranium}}[[#uranium|Uranium]]
|
* Deals 0.5 radiation damage per tick
|
* [[Researcher#CRG|CRG]] 2
|
{{:Chemical/Uranium}}
|N/A
|0,2
|N/A
|N/A
|-
|{{anchor|aluminium}}[[#aluminium|Aluminium]]
|N/A
|N/A
|
{{:Chemical/Aluminium}}
|N/A
|0,2
|N/A
|N/A
|-
|{{anchor|silicon}}[[#silicon|Silicon]]
|N/A
|N/A
|
{{:Chemical/Silicon}}
|N/A
|0,2
|N/A
|N/A
|-
|{{anchor|weldingfuel}}[[#weldingfuel|Welding Fuel]]
|
* Fire modifier
* Deals 0.5 toxin damage per tick
|
* [[Researcher#FUL|FUL]] 5
* [[Researcher#OXI|OXI]] 3
* [[Researcher#VIS|VIS]] 4
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Welding Fuel}}
|N/A
|0,2
|
* 30
* 50
|
* Deals 1.5 toxin damage per tick
* '''(C)''' Deals 4 toxin damage per tick
|-
|{{anchor|phoron}}[[#phoron|Phoron]]
|
* Fire modifier
* Deals 0.5 toxin damage per tick
|
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Phoron}}
|N/A
|0,1
|N/A
|N/A
|-
|{{anchor|radium}}[[#radium|Radium]]
|
* Deals 0.5 radiation damage per tick
|
* [[Researcher#CRG|CRG]] 2
|
{{:Chemical/Radium}}
|N/A
|0,2
|N/A
|N/A
|}

==Medical==
These chemicals are used for healing damage and generally keeping marines healthy. Some reagents that technically don't have a tangible gameplay effect but are in the medical chem code are included. (Mainly various antidepressants)
{| class="wikitable sortable" style="width: 100%;"
! style="width: 1%; margin: auto;" |Name
! style="width: 20%; margin: auto;" scope=col class=unsortable |Effect
! style="width: 12%; margin: auto;" scope=col class=unsortable |Properties
! style="margin: auto;" scope=col class=unsortable |Recipe
! style="width: 1%; margin: auto;" scope=col class=unsortable |Ratio
! style="width: 5%; margin: auto;" scope=col class=unsortable |Meta- bolism
! style="width: 1%; margin: auto;" scope=col class=unsortable |OD
! style="width: 20%; margin: auto;" scope=col class=unsortable |OD effects
|-
|{{anchor|inaprovaline}}[[#inaprovaline|Inaprovaline]]
|
* Prevents gaining further oxygen damage from being in crit.
|
* [[Researcher#CSL|CSL]] 3
|
* Weylandmeds.
{{:Chemical/Inaprovaline}}
|3:3
|0,2
|
* 60
* 100
|
* Knocks you out.
* Causes Jitter
* '''(C)''' Deals 0,5 heart damage per tick.
* '''(C)''' Sleeps you.
|-
|{{anchor|paracetamol}}[[#paracetamol|Paracetamol]]
|
* Reduces pain.
|
* [[Researcher#PNK|PNK]] 2
|
{{:Chemical/Paracetamol}}
|3:3
|0,05
|
* 60
* 100
|
* Makes you hallucinate.
* Deals 2 toxin damage per tick.
* '''(C)''' Deals 3 liver damage per tick.
* '''(C)''' Deals 1 brain damage per tick.
* '''(C)''' Deals 3 oxygen damage per tick.
|-
|{{anchor|ryetalyn}}[[#ryetalyn|Ryetalyn]]
|
* Fixes disabilities and disfigurements.
|
* [[Researcher#AID|AID]] 2
|
{{:Chemical/Ryetalyn}}
|2:2
|0,2
|
* 30
* 50
|
* Makes you confused.
* Deals 1 toxin damage per tick.
* '''(C)''' Knocks you out.
* '''(C)''' Deals 2 toxin damage per tick.
* '''(C)''' Deals 3 radiation damage per tick.
|-
|{{anchor|tramadol}}[[#tramadol|Tramadol]]
|
* Reduces pain.
|
* [[Researcher#PNK|PNK]] 5
|
* Weylandmeds.
{{:Chemical/Tramadol}}
|3:3
|0,05
|
* 30
* 50
|
* Makes you hallucinate.
* Deals 2.5 toxin damage per tick.
* '''(C)''' Deals 7.5 liver damage per tick.
* '''(C)''' Deals 2.5 brain damage per tick.
* '''(C)''' Deals 3 oxygen damage per tick.
|-
|{{anchor|oxycodone}}[[#oxycodone|Oxycodone]]
|
* Reduces pain.
|
* [[Researcher#PNK|PNK]] 8
|
* Weylandmeds.
{{:Chemical/Oxycodone}}
|2:1
|0,1
|
* 20
* 30
|
* Makes you hallucinate.
* Deals 4 toxin damage per tick.
* '''(C)''' Deals 12 liver damage per tick.
* '''(C)''' Deals 4 brain damage per tick.
* '''(C)''' Deals 3 oxygen damage.
|-
|{{anchor|leporazine}}[[#leporazine|Leporazine]]
|
* Attempts to stabilize your temperature.
|
* [[Researcher#TSL|TSL]] 2
|
{{:Chemical/Leporazine}}
|2:2
|0,2
|
* 30
* 50
|
* Knocks you out.
* '''(C)''' Sleeps you.
|-
|{{anchor|kelotane}}[[#kelotane|Kelotane]]
|
* Heals 1 burn damage per tick.
|
* [[Researcher#ACR|ACR]] 2
|
* Weylandmeds.
{{:Chemical/Kelotane}}
|2:2
|0,2
|
* 30
* 50
|
* Deals 1 brute and toxin damage per tick.
* '''(C)''' Deals 5.5 brute and toxin damage per tick.
|-
|{{anchor|dermaline}}[[#dermaline|Dermaline]]
|
* Heals 1.5 burn damage per tick.
|
* [[Researcher#ACR|ACR]] 3
|
{{:Chemical/Dermaline}}
|3:3
|0,2
|
* 15
* 25
|
* Deals 1.5 brute and toxin damage per tick.
* '''(C)''' Deals 9 brute and toxin damage per tick.
|-
|{{anchor|Meralyne}}[[#Meralyne|Meralyne]]
|
* Heals 1.5 brute damage per tick.
|
* [[Researcher#NGN|NGN]] 3
|
{{:Chemical/Meralyne}}
|3:3
|0,2
|
* 15
* 25
|
* Deals 1.5 burn damage per tick.
* '''(C)''' Deals 9 burn and 3 toxin damage per tick.
|-
|{{anchor|dexalin}}[[#dexalin|Dexalin]]
|
* Repairs 4 oxygen damage. 
* Removes 4u of [[#lexorin|lexorin]] per tick.
|
* [[Researcher#OXG|OXG]] 4
|
* Weylandmeds.
* Recipe:
{{:Chemical/Dexalin}}
|2,1:1
|0,2
|
* 30
* 50
|
* Deals 2 toxin damage per tick.
* '''(C)''' Deals 4 brute damage per tick.
* '''(C)''' Deals 8 toxin damage per tick.
|-
|{{anchor|dexalinplus}}[[#dexalinplus|Dexalin Plus]]
|
* Repairs all oxygen damage instantly.
* Removes 6u of [[#lexorin|lexorin]] per tick.
|
* [[Researcher#OXG|OXG]] 6
|
{{:Chemical/Dexalin Plus}}
|3:3
|0,2
|
* 15
* 25
|
* Deals 1.5 toxin damage per tick.
* '''(C)''' Deals 3 brute damage per tick.
* '''(C)''' Deals 7.5 toxin damage per tick.
|-
|{{anchor|tricordrazine}}[[#tricordrazine|Tricordrazine]]
|
* Heals 0.5 brute damage.
* Heals 0.5 burn damage.
* Heals 0.5 toxin damage.
* Heals 0.5 oxygen damage.
* Removes 1u of  all types of [[#toxin|toxin]].
|
* [[Researcher#NGN|NGN]] 1
* [[Researcher#ACR|ACR]] 1
* [[Researcher#ATX|ATX]] 1
* [[Researcher#OXG|OXG]] 1
|
{{:Chemical/Tricordrazine}}
|2:2
|0,2
|
* 30
* 50
|
* Deals 0.5 burn damage
* Deals 0.5 brute damage.
* Deals 0.25 toxin damage.
* Deals 0.5 Eye damage.
* '''(C)''' Deals 2.5 burn damage.
* '''(C)''' Deals 4 toxin damage.
* '''(C)''' Deals 2.5 brute damage.
* "(C)" Sleeps you
|-
|{{anchor|dylovene}}[[#dylovene|Dylovene]]
|
* Heals 2 toxin damage.
* Removes 1u of [[#toxin|toxin]] of any type.
* Removes 5u of [[#mindbreaker|mindbreaker toxin]].
* Removes 5u of [[#spacedrugs|space drugs]]
* Reduces the potency of hallucinations and other drug-related effects.
|
* [[Researcher#ATX|ATX]] 2
* [[Researcher#AHL|AHL]] 2
|
* Weylandmeds.
{{:Chemical/Dylovene}}
|3:3
|0,2
|
* 30
* 50
|
* Deals 1 eye damage..
* '''(C)''' Sleeps you.
* '''(C)''' Deals 1 burn damage.
* '''(C)''' Deals 1 brute damage.
* '''(C)''' Deals 2 toxin damage.

|-
|{{anchor|thwei}}[[#thwei|Thwei]]
|
* Heals 1,2 brute damage.
* Heals 1 toxin damage.
* Heals 1 organ damage.
* Removes 1u of [[#toxin|toxin]] of any type.
* Heals all oxygen damage.
* Removes 6u of [[#lexorin|lexorin]].
* Heals 6 radiation damage per tick.
* Repairs bones (splinted/unsplinted in minutes)
** Chest and groin: 3 / 7
** Head: 1 / 5
** Hands and feet: 0,5 / 0,5
** Arms and legs: 0,5 / 1
* Rapidly restores lost blood.
** '''(HUMAN ONLY)''' After blood is over maximum starts deals 9 brute, 9 burn, and 18 oxygen damage per tick.
* Fixes disabilities and disfigurements.
* Removes 5u of [[#mindbreaker|mindbreaker]].
* Removes 5u of [[#spacedrugs|space drugs]].
* Weakens drug-related effects.
* Removes 6u of [[#ethanol|ethanol]] and [[Drinks|other alcohol]].
* Fixes confusion, stuttering, temporary blindness, dizziness, jitteriness, and wakes you up.
* Fixes eye damage.
* Cures the zombie virus (black goo).
* Cures a certain other rare disease. 
|
* [[Researcher#XMB|XMB]] 1
* [[Researcher#ATX|ATX]] 1
* [[Researcher#HMG|HMG]] 9
* [[Researcher#OXG|OXG]] 6
* [[Researcher#ACG|ACG]] 6
* [[Researcher#BNM|BNM]] 6
* [[Researcher#AID|AID]] 1
* [[Researcher#AHL|AHL]] 2
* [[Researcher#FCS|FCS]] 6
* [[Researcher#CUR|CUR]] 4
|
{{:Chemical/Thwei}}
|N/A
|0,2
|N/A
|N/A
|-

|-
|{{anchor|neuraline}}[[#neuraline|Neuraline]]
|
* Weakens stuns and knockdowns.
* Fixes stuttering, blurry vision, confusion, dizziness, jitteriness and drowsiness.
|
* [[Researcher#NST|NST]] 5
|
{{:Chemical/Neuraline}}
|N/A
|0,4
|
* 2
* 3
|
* Deals 10 toxin damage.
* '''(C)''' Deals 5 brute damage.
* '''(C)''' Deals 5 burn damage.
* '''(C)''' Deals 15 toxin damage.
|-
|{{anchor|arithrazine}}[[#arithrazine|Arithrazine]]
|
* Heals 1 toxin damage.
* Removes 1u of any type of [[#toxin|toxin]].
* Deals 1 brute damage.
|
* [[Researcher#ATX|ATX]] 1
* [[Researcher#BCD|BCD]] 1
|
{{:Chemical/Arithrazine}}
|2:2
|0,05
|
* 15
* 25
|
* Deals 1 eye damage.
* Deals 2 brute damage.
* '''(C)''' Sleeps you.
* '''(C)''' Deals 4 brute damage.
|-
|{{anchor|russianred}}[[#russianred|Russian Red]]
|
* Heals 1 toxin damage.
* Removes 1u of any type of [[#toxin|toxin]].
* Deals 2 brute damage.
|
* [[Researcher#ATX|ATX]] 1
* [[Researcher#BCD|BCD]] 2
|
{{:Chemical/Russian Red}}
|N/A
|1
|
* 20
* 30
|
* Deals 1 eye damage.
* Deals 4 brute damage.
* '''(C)''' Sleeps you.
* '''(C)''' Deals 8 brute damage.
|-
|{{anchor|alkysine}}[[#alkysine|Alkysine]]
|
* Heals 3 brain damage per tick.
|
* [[Researcher#NRP|NRP]] 2
|
{{:Chemical/Alkysine}}
|3:2
|0,05
|
* 30
* 50
|
* Deals 1 toxin damage.
* '''(C)''' Deals 3 brain damage.
* '''(C)''' Stuns you.
|-
|{{anchor|imidazoline}}[[#imidazoline|Imidazoline]]
|
* Heals 1 eye damage.
* Fixes blurry vision and blindness.
|
* [[Researcher#OCP|OCP]] 2
|
{{:Chemical/Imidazoline}}
|3:2
|0,2
|
* 30
* 50
|
* Deals 1 toxin damage.
* '''(C)''' Deals 1 brute damage.
* '''(C)''' Deals 1 burn damage.
* '''(C)''' Deals 4 toxin damage.
* '''(C)''' Deals 1 brain damage.
|-
|{{anchor|peridaxon}}[[#peridaxon|Peridaxon]]
|
* Prevents you from suffering consequences of organ damage.
* Does '''NOT''' fix organs.
|
* [[Researcher#OGS|OGS]] 4
|
* Weylandmeds.
* Recipe:
{{:Chemical/Peridaxon}}
|4:2
|0,05
|
* 15
* 25
|
* Deals 2 brute damage.
* '''(C)''' Deals 8 brute damage.
* '''(C)''' Deals 6 burn damage.
* '''(C)''' Deals 6 toxin damage.
|-
|{{anchor|bicaridine}}[[#bicaridine|Bicaridine]]
|
* Heals 1 brute damage per tick.
|
* [[Researcher#NGN|NGN]] 2
|
* Weylandmeds.
* Recipe:
{{:Chemical/Bicaridine}}
|2:2
|0,2
|
* 30
* 50
|
* Deals 1 burn damage.
* '''(C)''' Deals 6 burn damage
* '''(C)''' Deals 2 toxin damage.
|-
|{{anchor|epinephrine}}[[#epinephrine|Epinephrine]]
|
* '''MUST BE INJECTED. CANNOT TAKE IN PILLS.'''
* Increases defibrillator healing by 16 per damage type.
* Reduces pain.
* Makes you move faster.
* A small amount is consumed on each defib attempt.
|
* [[Researcher#PNK|PNK]] 1,5 
* [[Researcher#EGN|EGN]] 4
* [[Researcher#INV|INV]] 1
|
{{:Chemical/Epinephrine}}
|3:2
|0,4
|
* 10,5
* 20
|
* '''(C)''' Deals 1 brute damage.
|-
|{{anchor|ultrazine}}[[#ultrazine|Ultrazine]]
|
* Makes you much faster.
* Makes you addicted to it.
|
* [[Researcher#MST|MST]] 40
* [[Researcher#ADT|ADT]] 8
|
{{:Chemical/Ultrazine}}
|N/A
|0,0167 
|
* 10,5
* 20
|
* Deals 40 heart damage.
* Deals 8 brain damage.
* '''(C)''' Deals 40 brute damage.
* '''(C)''' Makes you nervous. 

|-
|{{anchor|cryoxadone}}[[#cryoxadone|Cryoxadone]]
|
* ''' ONLY FUNCTIONS AT LOW TEMPERATURES. USE A CRYO TUBE.''' 
* Heals 3 radiation damage.
* Heals 3 brute damage.
* Heals 3 burn damage.
* Heals 3 toxin damage.
* Heals 1 oxygen damage.
|
* [[Researcher#CMB|CMB]] 2
* [[Researcher#NGN|NGN]] 1
* [[Researcher#ACR|ACR]] 1
* [[Researcher#ATX|ATX]] 1
* [[Researcher#ACG|ACG]] 1
|
{{:Chemical/Cryoxadone}}
|3:3
|0,2
|N/A
|N/A
|-
|{{anchor|clonexadone}}[[#clonexadone|Clonexadone]]
|
* '''AS ABOVE''' 
* Heals 6 radiation damage.
* Heals 6 brute damage.
* Heals 6 burn damage.
* Heals 6 toxin damage.
|
* [[Researcher#CMB|CMB]] 6
* [[Researcher#NGN|NGN]] 3
* [[Researcher#ACR|ACR]] 3
* [[Researcher#ATX|ATX]] 3
* [[Researcher#ACG|ACG]] 3
|
{{:Chemical/Clonexadone}}
|2,1:2
|0,2
|N/A
|N/A
|-
|{{anchor|rezadone}}[[#rezadone|Rezadone]]
|
* Heals 1 brute damage.
* Removes disabilities and disfigurements.
* Heals 2 radiation damage.
* Deals 2 toxin damage.
|
* [[Researcher#NGN|NGN]] 1
* [[Researcher#AID|AID]] 3
* [[Researcher#TOX|TOX]] 2
* [[Researcher#ACG|ACG]] 2
|
{{:Chemical/Rezadone}}
|3:3
|0,2
|
* 30
* 50
|
* Deals 1 burn damage.
* Makes you confused.
* Deals 11 toxin damage.
* '''(C)''' Knocks you out.
* '''(C)''' Deals 13 toxin damage.
* '''(C)''' Deals 9 radiation damage.
* '''(C)''' Deals 4 burn damage.
* '''(C)''' Deals 4 brute damage.
|-
|{{anchor|spaceacillin}}[[#spaceacillin|Spaceacillin]]
|
* Cures mundane infections like the flu.
|
* [[Researcher#UNK|UNK]] 1
|
{{:Chemical/Spaceacillin}}
|2:2
|0,01
|
* 30
* 50
|
* Deals 1 brute damage.
* '''(C)''' Deals 3 brute damage.
* '''(C)''' Deals 3 burn damage.
* '''(C)''' Deals 3 toxin damage.
|-
|{{anchor|ethylredoxrazine}}[[#ethylredoxrazine|Ethylredoxrazine]]
|
* Removes confusion, drowsiness, stuttering, blurry vision, blindness, dizziness, and jitteriness.
* Removes 3u [[#ethanol|ethanol]] and [[Drinks|other alcohols]] from the body.
* Reacts with [[#ethanol|ethanol]] to turn into water.
|
* [[Researcher#FCS|FCS]] 3
|
{{:Chemical/Ethylredoxrazine}}
|3:3
|0,2
|
* 30
* 50
|
* Deals 1.5 toxin damage per tick
* '''(C)''' Deals 6 toxin damage per tick
|-
|{{anchor|methylphenidate}}[[#methylphenidate|Methylphenidate]]
|
* Gives you messages about your mind becoming clearer.
* Removes confusion.
|
* [[Researcher#PST|PST]] 4
|
{{:Chemical/Methylphenidate}}
|2:3
|0,01
|N/A
|N/A
|-
|{{anchor|citalopram}}[[#citalopram|Citalopram]]
|
* As above.
|
* [[Researcher#PST|PST]] 2
|
{{:Chemical/Citalopram}}
|2:3
|0,01
|N/A
|N/A
|-
|{{anchor|paroxetine}}[[#paroxetine|Paroxetine]]
|
* As above.
* Makes you hallucinate.
* Makes you jittery.
|
* [[Researcher#PST|PST]] 6
* [[Researcher#HLG|HLG]] 6
|
{{:Chemical/Paroxetine}}
|3:3
|0,01
|N/A
|N/A
|-
|{{anchor|antized}}[[#antized|Anti-Zed]]
|
* Prevents zombies from reviving.
* Cures the zombie virus.
* Cures all other diseases as well.
|
* [[Researcher#CUR|CUR]] 2
|
{{:Chemical/Anti-Zed}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|sterilizine}}[[#sterilizine|Sterilizine]]
|
* Sterilizes surfaces. Since we don't actually need to do that, this has no use outside of RP.
|N/A
|
{{:Chemical/Sterilizine}}
|3:3
|0,2
|N/A
|N/A
|-
|{{anchor|soporific}}[[#soporific|Soporific]]
|
* Puts you to sleep.
* Reduces pain.
|
* [[Researcher#PNK|PNK]] 10
* [[Researcher#SDT|SDT]] 2
|
{{:Chemical/Soporific}}
|5:5
|0,1
|
* 30
* 50
|
* Makes you hallucinate.
* Deals 5 toxin damage.
* '''(C)''' Deals 15 liver damage.
* '''(C)''' Deals 5 brain damage.
* '''(C)''' Deals 3 oxygen damage.
|-
|{{anchor|vaccine}}[[#vaccine|Vaccine]]
|
* Prevents you from catching the virus this is a vaccine against.
* Cures the zombie virus.
* Prevents dead zombies from reviving.
* Cures all other diseases as well.
|
* [[Researcher#CUR|CUR]] 4
|
{{:Chemical/Vaccine}}
|N/A
|0,2
|N/A
|N/A
|-
|{{anchor|antineurotoxin}}[[#antineurotoxin|Anti-Neurotoxin]]
|
* Note that '''technically''', as far as the code is concerned, this is a subtype of xeno plasmas.
* Protects you from [[Sentinel|getting shot with any kind of neuro]].
|
* [[Researcher#NRS|NRS]] 1
|
{{:Chemical/Anti-Neurotoxin}}
|2:1
|0,4
|
* 30
* 50
|
* Deals 1 liver damage.
* '''(C)''' Deals 2 brain damage.
|-
|{{anchor|lipozine}}[[#lipozine|Lipozine]]
|
* Causes you to lose fat and makes you hungry
|
* [[Researcher#KTG|KTG]] 4
|
{{:Chemical/Lipozine}}
|3:3
|0.05
|
* 30
* 50
|
* Makes you even more hungry
* '''(C)''' Deals 2 toxin Damage
|}

==Toxins and acids==
Most of these chemicals generally don't have much use outside of murder.
{| class="wikitable unsortable" style="width: 100%;"
! style="width: 10%; margin: auto;" |Name
! style="width: 20%; margin: auto;" |Effect
! style="width: 12%; margin: auto;" |Properties
! style="margin: auto;" |Recipe
! style="width: 5%; margin: auto;" |Ratio
! style="width: 5%; margin: auto;" |Meta- bolism
! style="width: 5%; margin: auto;" |OD
! style="width: 20%; margin: auto;" |OD effects
|-
|{{anchor|generictoxin}}[[#generictoxin|Generic Toxin]]
|
* Most other chemicals in this table are a subtype of this one.
* Deals 1 toxin damage every tick.
|
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Generic Toxin}}
|N/A
|0,1
|N/A
|N/A
|-
|{{anchor|toxin}}[[#toxin|Toxin]]
|
* Deals 0.5 toxin damage per tick.
|
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Toxin}}
|2:2
|1
|N/A
|N/A
|-

|-
|{{anchor|mutagen}}[[#mutagen|Unstable Mutagen]]
|
* Deals 0,5 radiation damage per tick.
|
* [[Researcher#CRG|CRG]] 1
|
{{:Chemical/Unstable Mutagen}}
|3:3
|0,1
|N/A
|N/A
|-
|{{anchor|lexorin}}[[#lexorin|Lexorin]]
|
* Deals 8 oxygen damage per tick.
* Deals 0.5 brute damage per tick.
|
* [[Researcher#HPX|HPX]] 8
* [[Researcher#BCD|BCD]] 1
|
{{:Chemical/Lexorin}}
|3:3
|0,1
|
* 30
* 50
|
* Deals 5.5 brute damage.
* Deals 4 toxin damage.
* Deals 28 oxygen damage.
* '''(C)''' Deals 28 brute and oxygen damage.
* '''(C)''' Deals 12 toxin damage.
|-
|{{anchor|cyanide}}[[#cyanide|Cyanide]]
|
* Deals 8 oxygen damage.
* Puts you to sleep after a while.
|
* [[Researcher#HPX|HPX]] 4
* [[Researcher#SDT|SDT]] 1
|
{{:Chemical/Cyanide}}
|N/A
|0,4
|N/A
|N/A
|-
|{{anchor|minttoxin}}[[#minttoxin|Mint Toxin]]
|
* Deals 1 toxin damage.
|
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Mint Toxin}}
|N/A
|0,1
|N/A
|N/A
|-
|{{anchor|carpotoxin}}[[#carpotoxin|Carpotoxin]]
|
* Deals 2 toxin damage.
|
* [[Researcher#TOX|TOX]] 2
|
{{:Chemical/Carpotoxin}}
|N/A
|0,1
|N/A
|N/A

|-
|{{anchor|chloralhydrate}}[[#chloralhydrate|Chloral Hydrate]]
|
* Deals 0.5 toxin damage.
* Puts you to sleep.
|
* [[Researcher#SDT|SDT]] 6
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Chloral Hydrate}}
|
|0,1
|
* 15
* 25
|
* Deals 1.5 toxin damage.
* Knocks you out.
* '''(C)''' Deals 4 toxin damage.
* '''(C)''' Deals 15 oxygen damage.
|-
|{{anchor|potassiumchloride}}[[#potassiumchloride|Potassium Chloride]]
|
* Fire modifier.
* Deals 4 oxygen damage.
* Slows you.
|
* [[Researcher#HPX|HPX]] 2
* [[Researcher#RLX|RLX]] 4
|
{{:Chemical/Potassium Chloride}}
|2:2
|0,2
|30
|
* Deals 2 brute damage.
* Deals 2 toxin damage.
* Deals 10 oxygen damage.
* Slows you down by a lot.
|-
|{{anchor|potassiumchlorophoride}}[[#potassiumchlorophoride|Potassium Chlorophoride]]
|
* Slows you down.
* Deals 8 oxygen damage.
* Deals 2 toxin damage.
|
* [[Researcher#RLX|RLX]] 8
* [[Researcher#HPX|HPX]] 4
* [[Researcher#TOX|TOX]] 2
|
{{:Chemical/Potassium Chlorophoride}}
|3:4
|0,2
|20
|
* Deals 4 brute damage.
* Deals 4 toxin damage.
* Deals 20 oxygen damage.
* Deals 4 toxin damage.
* Slows you down by a lot.

|-
|{{anchor|sulphuricacid}}[[#sulphuricacid|Sulphuric Acid]]
|
* Has a chance to melt items when poured/sprayed on them. Worn headgear included.
* Deals 0.5 toxin damage per tick.
* Deals 1.5 burn damage per tick.
|
* [[Researcher#TOX|TOX]] 1
* [[Researcher#CRS|CRS]] 3
|
{{:Chemical/Sulphuric Acid}}
|7:1
|0,1
|N/A
|N/A
|-
|{{anchor|polytrinicacid}}[[#polytrinicacid|Polytrinic Acid]]
|
* As above, but a higher chance to melt.
* Deals 1 toxin damage per tick.
* Deals 1.5 burn damage per tick.
|
* [[Researcher#CRS|CRS]] 3
* [[Researcher#TOX|TOX]] 2
|
{{:Chemical/Polytrinic Acid}}
|3:3
|0,1
|N/A
|N/A
|-
|{{anchor|formaldehyde}}[[#formaldehyde|Formaldehyde]]
|
* Deals 1 toxin damage.
* Deals 0,5 radiation damage.
* Ingredient for explosives.
|
* [[Researcher#TOX|TOX]] 1
* [[Researcher#CRG|CRG]] 1
|
{{:Chemical/Formaldehyde}}
|3:3
|0,1
|N/A
|N/A
|-
|{{anchor|paraformaldehyde}}[[#paraformaldehyde|Paraformaldehyde]]
|
* Deals 1 toxin damage.
* Ingredient for explosives.
|
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Paraformaldehyde}}
|2:1
|0,1
|N/A
|N/A
|-
|{{anchor|impedrezene}}[[Chemistry#impedrezene|Impedrezene]]
|
* Deals 3,5 brain damage.
* Slows you down.
|
* [[Researcher#NRT|NRT]] 2
* [[Researcher#RLX|RLX]] 1
|
{{:Chemical/Impedrezene}}
|3:2
|0,2
|
* 30
* 50
|
* Deals 6 brain damage.
* Makes you sleepier.
* Slows you down by a lot.
* '''(C)''' Has a chance to knock you out.
* '''(C)''' Deals 1 oxygen damage.
* '''(C)''' Deals 0,75 heart damage.
* '''(C)''' Has a chance to knock you down.
|}

==Drugs==
Reagents that get marines high.
{| class="wikitable unsortable" style="width: 100%;"
! style="width: 10%; margin: auto;" |Name
! style="width: 20%; margin: auto;" |Effect
! style="width: 12%; margin: auto;" |Properties
! style="margin: auto;" |Recipe
! style="width: 5%; margin: auto;" |Ratio
! style="width: 5%; margin: auto;" |Meta- bolism
! style="width: 5%; margin: auto;" |OD
! style="width: 20%; margin: auto;" |OD effects
|-
|{{anchor|mindbreaker}}[[#mindbreaker|Mindbreaker Toxin]]
|
* Literally LSD.
* Makes you hallucinate.
* Makes you high.
* Makes you jittery.
|
* [[Researcher#HLG|HLG]] 8
|
{{:Chemical/Mindbreaker Toxin}}
|3:3
|0,1
|
* 30
* 50
|
* Makes you hallucinate more.
* Makes you stumble around.
* '''(C)''' Deals 4 brain damage.
* '''(C)''' Knocks you out.
|-
|{{anchor|spacedrugs}}[[#spacedrugs|Space Drugs]]
|
* Baby's first drug.
* Makes you high.
|
* [[Researcher#HLG|HLG]] 2
|
{{:Chemical/Space Drugs}}
|3:3
|0,2
|
* 30
* 50
|
* Makes you hallucinate.
* Makes you jittery.
* '''(C)''' Deals 2 brain damage.
* '''(C)''' Knocks you out.
|-
|{{anchor|psilocybin}}[[#psilocybin|Psilocybin]]
|
* Makes you high.
* Makes you hallucinate.
* Makes you jittery.
|
* [[Researcher#HLG|HLG]] 3
|
{{:Chemical/Psilocybin}}
|N/A
|0,2
|
* 30
* 50
|
* Makes you hallucinate more.
* Makes you stumble around.
* '''(C)''' Deals 3 brain damage.
* '''(C)''' Knocks you out.
|-
|{{anchor|nicotine}}[[#nicotine|Nicotine]]
|N/A 
|N/A
|
{{:Chemical/Nicotine}}
|N/A
|0,2
|N/A
|N/A
|}

==Xeno blood and plasma==
Chemicals acquired from xenos.
{| class="wikitable unsortable" style="width: 100%;"
! style="width: 10%; margin: auto;" |Name
! style="width: 20%; margin: auto;" |Effect
! style="width: 12%; margin: auto;" |Properties
! style="margin: auto;" |Recipe
! style="width: 5%; margin: auto;" |Ratio
! style="width: 5%; margin: auto;" |Meta- bolism
! style="width: 5%; margin: auto;" |OD
! style="width: 20%; margin: auto;" |OD effects
|-
|{{anchor|xenoblood}}[[#xenoblood|Acidic Blood]]
|
* Deals 3 burn damage.
|
* [[Researcher#CRS|CRS]] 3
|
{{:Chemical/Acidic Blood}}
|N/A
|N/A
|N/A
|N/A
|-
|{{anchor|royalxenoblood}}[[#royalxenoblood|Dark Acidic Blood]]
|
* Deals 6 burn damage.
|
* [[Researcher#CRS|CRS]] 6
|
Queen and Praetorians.
|N/A
|N/A
|N/A
|N/A
|-
|{{anchor|plasma}}[[#plasma|Plasma]]
|
* Base type for all of the following.
|N/A
|{{:Chemical/Plasma}}
|N/A
|0,4
|N/A
|N/A
|-
|{{anchor|pheromoneplasma}}[[#pheromoneplasma|Pheromone Plasma]]
|
* Makes you high.
* Makes you hallucinate.
* Helps you with knockdowns, knockouts and stuns.
* Fixes stuttering, confusion, blurry vision, drowsiness, dizziness, and jitteriness.
|
* [[Researcher#HLG|HLG]] 8
* [[Researcher#NST|NST]] 6
|
{{:Chemical/Pheromone Plasma}}
|N/A
|0,4
|30
|
* Makes you stumble around.
* Makes you hallucinate more.
* Deals 12 toxin damage.
* '''(C)''' Deals 8 brain damage.
* '''(C)''' Knocks you out.
* '''(C)''' Deals 6 brute damage.
* '''(C)''' Deals 6 burn damage.
* '''(C)''' Deals 18 toxin damage.
|-
|{{anchor|chitinplasma}}[[#chitinplasma|Chitin Plasma]]
|
* Prevents fractures.
|
* [[Researcher#HDN|HDN]] 1
|
{{:Chemical/Chitin Plasma}}
|N/A
|0,4
|
* 30
* 50
|
* Slows you down.
* '''(C)''' Deals 3 brute damage.
|-
|{{anchor|catecholamineplasma}}[[#catecholamineplasma|Catecholamine Plasma]]
|
* Applies pain.
* Makes you faster.
|
* [[Researcher#PNG|PNG]] 2
* [[Researcher#MST|MST]] 6
|
{{:Chemical/Catecholamine Plasma}}
|N/A
|0,4
|
* 30
* 50
|
* Increased pain.
* Deals 2 brute damage.
* Deals 6 heart damage.
* '''(C)''' Deals 10 brute damage.
|-
|{{anchor|eggplasma}}[[#eggplasma|Egg Plasma]]
|
* Infects with a xeno larva.
* Makes more of itself by draining blood.
|
* [[Researcher#HST|HST]] 4
|
{{:Chemical/Egg Plasma}}
|
|0,4
|
* 80
* 100
|
* Drains blood and replicates itself faster.
* '''(C)''' Makes you nervous.
|-
|{{anchor|neurotoxinplasma}}[[#neurotoxinplasma|Neurotoxin Plasma]]
|
* Not to be confused with the [[Drinks#neurotoxin|drink]].
* Deals 7 brain damage.
* Deals 1 toxin damage.
* Makes you high.
* Makes you hallucinate.
* Makes you jittery.
|
* [[Researcher#NRT|NRT]] 4
* [[Researcher#TOX|TOX]] 1
* [[Researcher#HLG|HLG]] 6
|
{{:Chemical/Neurotoxin Plasma}}
|
|0,4
|
* 30
* 50
|
* Deals 12 brain damage.
* Makes you stumble around.
* Makes you hallucinate more.
* Makes you more jittery.
* Makes you drowsy.
* Deals 2 toxin damage.
* '''(C)''' Knocks you out.
* '''(C)''' Deals 6 brain damage.
* '''(C)''' Applies the same effect as getting shot with [[Sentinel|neuro]].
* '''(C)''' Deals 4 toxin damage.
|-
|{{anchor|purpleplasma}}[[#purpleplasma|Purple Plasma]]
|
* Deals 2 brute damage.
|
* [[#BCD|BCD]] 2
|
{{:Chemical/Purple Plasma}}
|N/A
|0,4
|
* 30
* 50
|
* Deals 4 brute damage.
* '''(C)''' Deals 8 brute damage.
|-
|{{anchor|royalplasma}}[[#royalplasma|Royal Plasma]]
|
* Makes you addicted to itself.
* Deals 4 brute damage.
* Makes you hallucinate.
* Makes you high.
* Makes you jittery.
|
* [[Researcher#BCD|BCD]] 4
* [[Researcher#ADT|ADT]] 1
* [[Researcher#HLG|HLG]] 4
* [[Researcher#CIP|CIP]] 1
|
{{:Chemical/Royal Plasma}}
|N/A
|0,4
|
* 30
* 50
|
* Deals 1 brain damage.
* Deals 8 brute damage.
* Makes you stumble around.
* Makes you hallucinate more.
* Makes you more jittery
* '''(C)''' Deals 4 brain damage.
* '''(C)''' Knocks you out.
* '''(C)''' Deals 16 brute damage.
* '''(C)''' Makes you nervous.
|}

==Other==
This contains reagents that don't neatly fit into other categories.
{| class="wikitable unsortable" style="width: 100%;"
! style="width: 10%; margin: auto;" |Name
! style="width: 20%; margin: auto;" |Effect
! style="width: 12%; margin: auto;" |Properties
! style="margin: auto;" |Acquiring
! style="width: 5%; margin: auto;" |Ratio
! style="width: 5%; margin: auto;" |Meta- bolism
! style="width: 5%; margin: auto;" |OD
! style="width: 20%; margin: auto;" |OD effects
|-
|{{anchor|fertilizer}}[[#fertilizer|Fertilizer]]
|
* Usable as fertilizer for plants.
* Deals 0,5 toxin damage.
|
* [[Researcher#TOX|TOX]] 0,5
|
{{:Chemical/Fertilizer}}
|N/A
|0,1
|N/A
|N/A
|-
|{{anchor|plantbgone}}[[#plantbgone|Plant-B-Gone]]
|
* Kills xeno weeds.
* Kills normal weeds.
* Harms helpful plants in hydro trays too.
* Deals 1 toxin damage.
|
* [[Researcher#TOX|TOX]] 2
|
{{:Chemical/Plant-B-Gone}}
|5:5
|0,1
|N/A
|N/A
|-
|{{anchor|smoke}}[[#smoke|Smoke]]
|
* Creates smoke
|N/A
|
{{:Chemical/Smoke}}
|N/A
|N/A
|N/A
|N/A
|-
|{{anchor|flashpowder}}[[#flashpowder|Flash Powder]]
|
* Creates a bright light that lasts for a while.
|N/A
|
{{:Chemical/Flash Powder}}
|N/A
|N/A
|N/A
|N/A
|-
|{{anchor|blood}}[[#blood|Blood]]
|
* Spreads diseases if injected.
* Restores blood volume when injected into a human.
** Deals toxin damage if blood type is incorrect. (Just use O-)
|N/A
|
{{:Chemical/Blood}}
|N/A
|N/A
|N/A
|N/A
|-
|{{anchor|plasticide}}[[#plasticide|Plasticide]]
|
* Deals 1 toxin damage.
* Turns into plastic when mixed at a 20:10 ratio with [[#sulphuricacid|Sulphuric Acid]].
|
* [[Researcher#TOX|TOX]] 1
|{{:Chemical/Plasticide}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|serotrotium}}[[#serotrotium|Serotrotium]]
|
* Makes you sneeze, blink and cough.
|
* [[Researcher#ALG|ALG]] 2
|{{:Chemical/Serotrotium}}
|N/A
|0,2
|
* 30
* 50
|N/A
|-
|{{anchor|glycerol}}[[#glycerol|Glycerol]]
|
* Used for making nitroglycerin.
|N/A
|
{{:Chemical/Gylcerol}}
|4:1
|0,01
|N/A
|N/A
|-
|{{anchor|virusfood}}[[#virusfood|Virus Food]]
|
* No pathology on CM. So this is entirely useless.
* Satiates you.
|
* [[Researcher#NTR|NTR]] 2
|
{{:Chemical/Virus Food}}
|3:3
|0,2
|N/A
|N/A
|-
|{{anchor|thermite}}[[#thermite|Thermite]]
|
* Fire modifier.
* Deals 1 burn damage.
* Can be applied to walls either directly or with a spray bottle and then ignited to melt through them.
|
* [[Researcher#FUL|FUL]] 7
* [[Researcher#OXI|OXI]] 5
* [[Researcher#VIS|VIS]] 4
* [[Researcher#CRS|CRS]] 2
|
{{:Chemical/Thermite}}
|3:3
|0,2
|N/A
|N/A
|-
|{{anchor|spacecleaner}}[[#spacecleaner|Space Cleaner]]
|
* Cleans objects when splashed/sprayed on them.
* Use a spray bottle filled with it to clean a dirty microwave.
|N/A
|
{{:Chemical/Space Cleaner}}
|3:2
|0,2
|
* 30
* 50
|
* Unless there's some snowflake code tucked away in a deep dark corner of CM, this has no effects on OD.
|-
|{{anchor|cryptobiolin}}[[#cryptobiolin|Cryptobiolin]]
|
* Used for making spaceacillin.
|N/A
|
{{:Chemical/Cryptobiolin}}
|3:3
|0,2
|N/A
|N/A


|-
|{{anchor|fluorosurfactant}}[[#fluorosurfactant|Fluorosurfactant]]
|
* Turns into foam when mixed with [[#water|water]] at a 1:1 ratio.
|N/A
|
{{:Chemical/Fluorosurfactant}}
|5:5
|0,2
|N/A
|N/A
|-
|{{anchor|foamingagent}}[[#foamingagent|Foaming Agent]]
|
* Creates metal foam when 1u is mixed with 1u [[#polytrinicacid|polytrinic acid]] and 3u [[#aluminuim|aluminium]] or 3u [[#iron|iron]].
|N/A
|
{{:Chemical/Foaming Agent}}
|2:1
|0,2
|N/A
|N/A
|-
|{{anchor|ammonia}}[[#ammonia|Ammonia]]
|
* Used for explosives.
|N/A
|
{{:Chemical/Ammonia}}
|4:3
|0,2
|N/A
|N/A
|-
|{{anchor|hexamine}}[[#hexamine|Hexamine]]
|
* As above.
|N/A
|
{{:Chemical/Hexamine}}
|5:3
|0,2
|N/A
|N/A

|-
|{{anchor|diethylamine}}[[#diethylamine|Diethylamine]]
|
* Fertilizer.
|N/A
|
{{:Chemical/Diethylamine}}
|2:2
|0,2
|N/A
|N/A
|-
|{{anchor|blackgoo}}[[#blackgoo|Black Goo]]
|
* Gives you the zombie virus.
|
* [[Researcher#RAV|RAV]] 1
|{{:Chemical/Black Goo}}
|N/A
|100
|N/A
|N/A
|-
|{{anchor|dinitroaniline}}[[#dinitroaniline|Dinitroaniline]]
|
* A herbicide and pesticide mixture used in hydroponics
* Deals 1 toxin damage.
|
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Dinitroaniline}}
|3:3
|0.2
|N/A
|N/A
|}

==Explosives and flammable chems==
This contains reagents that can be used for making explosives. They may be duplicates of ones already present in one of the previous tables.
{| class="wikitable unsortable" style="width: 100%;"
! style="width: 10%; margin: auto;" |Name
! style="width: 20%; margin: auto;" |Recipe
! style="width: 10%; margin: auto;" |Ratio
! style="width: 10%; margin: auto;" |Power
! style="width: 10%; margin: auto;" |Falloff
! style="width: 10%; margin: auto;" |Intensity
! style="width: 10%; margin: auto;" |Radius
! style="width: 10%; margin: auto;" |Duration
! style="width: 10%; margin: auto;" |Fire colour
|-
| [[#water|Water]]
|
{{:Chemical/Water}}
| 3:1
| 0
| 0
| -3
| 0
| 0
| N/A
|-
| [[#oxygen|Oxygen]]
| {{:Chemical/Oxygen}}
| N/A
| 0
| 0
| 0,75
| -0,08
| 0
| #58daff (light blue)
|-
| [[#copper|Copper]]
| {{:Chemical/Copper}}
| N/A
| 0
| 0
| 0
| 0
| 0
| #78be5a (green)
|-
| [[#hydrogen|Hydrogen]]
| {{:Chemical/Hydrogen}}
| N/A
| 0,15
| 0
| -0,5
| 0,2
| -0,5
| #b6f8ff (super light blue)
|-
| [[#carbon|Carbon]]
| {{:Chemical/Carbon}}
| N/A
| 0
| 0
| 0
| 0
| 1
| #ffd700 (gold)
|-
| [[#phosphorus|Phosphorus]]
| {{:Chemical/Phosphorus}}
| N/A
| 0
| 0
| 1
| -0,12
| 0,1
| #ffdba4
|-
| [[#lithium|Lithium]]
| {{:Chemical/Lithium}}
| N/A
| 0
| 0
| 0,35
| -0,01
| -0,1
| #ff356f (dark pink)
|-
| [[#thermite|Thermite]]
|
{{:Chemical/Thermite}}
| 3:3
| 0,5
| 1
| 0,3
| -0,08
| 0,9
| #ffb300 (orange)
|-
| [[#fuel|Welding Fuel]]
| {{:Chemical/Welding Fuel}}
| N/A
| 0,12
| -0,1
| 0,1
| -0,08
| 0,7
| #ff9900 (orange)
|-
| [[#hexamine|Hexamine]]
|
{{:Chemical/Hexamine}}
| 5:2
| 0
| 0
| 0
| 0
| 0,5
| #ff9900 (as above)
|-
| [[#napalm|Napalm]]
|
{{:Chemical/Napalm}}
| 3:1
| 0
| 0
| 0,45
| 0,06
| 0,75
| #D05006 (dark orange)
|-
| {{anchor|clf3}}[[#clf3|CLF3 (Chlorine Trifluoride )]]
|
{{:Chemical/Chlorine Triflouride}}
| 4:1
| 0
| 0
| 1,6
| -0,08
| -0,8
| #ff9300 (orange)
|-
| [[#methane|Methane]]
|
{{:Chemical/Methane}}
| 5:1
| 0,15
| 0
| -0,35
| 0,095
| 0,25
| #00a5ff (blue)
|-
| {{anchor|ammoniumnitrate}}[[#ammoniumnitrate|Ammonium Nitrate]]
|
{{:Chemical/Ammonium Nitrate}}
| 2:2
| 0,4
| 1,5
| 0,5
| 0
| -0,2
| #ff9900 (orange)
|-
| {{anchor|anfo}}[[#anfo|Ammonium Nitrate Fuel Oil]]
|
{{:Chemical/Ammonium Nitrate Fuel Oil}}
| 3:2
| 1
| -0,6
| 0
| 0
| 0
| N/A
|-
| {{anchor|nitroglycerin}}[[#nitroglycerin|Nitroglycerin]]
|
{{:Chemical/Nitroglycerin}}
| 3:2
| 1
| -0,5
| 0
| 0
| 0
| N/A
|-
| {{anchor|cyclonite}}[[#cyclonite|Cyclonite]]
|
{{:Chemical/Cyclonite}}
| 2:2
| 1,5
| -0,4
| 0
| 0
| 0
| N/A
|-
| {{anchor|octogen}}[[#octogen|Octogen]]
|
{{:Chemical/Octogen}}
| 4:2
| 2
| -0,2
| 0,4
| -0,02
| -0,2
| Orange 
|-
| {{anchor|potassiumhydroxide}}[[#potassiumhydroxide|Potassium Hydroxide]]
|
* Explodes INSTANTLY and can't be stabilized. Don't use this. It's garbage.
{{:Chemical/Potassium Hydroxide}}
| 2:1
| 0,5
| 0
| 0
| 0
| 0
| N/A
|-
| [[#phoron|Phoron]]
| {{:Chemical/Phoron}}
| N/A
| 0
| 0
| 0,4
| 0,05
| -0,8
| #e01e1e (red)
|-
| [[#potassiumchloride|Potassium Chloride]]
|
{{:Chemical/Potassium Chloride}}
| 2:2
| 0
| 0
| 0,1
| 0
| 0
| #800080 (purple)
|-
| {{anchor|salt}}[[#salt|Table Salt]]
|
{{:Chemical/Table Salt}}
| 1:1
| 0
| 0
| 0,1
| 0
| 0
| #ffff00 (yellow)
|-
| {{anchor|stickynapalm}}[[#stickynapalm|Sticky Napalm]]
|
{{:Chemical/Sticky Napalm}}
| 1:1
| 0
| 0
| 0,2
| 0,5
| 0,5
| #f8e3b2 (barley white)
|-
| {{anchor|hcnapalm}}[[#hcnapalm|High-Combustion Napalm]]
|
{{:Chemical/High-Combustion Napalm}}
| 1:1
| 0
| 0
| 0,8
| 0,1
| 0,5
| #742424 (dark red)
|}

<br>

= Additional User made information=
* [https://cm-ss13.com/forums/showthread.php?3414-Magnus-Opus-on-Reasearch-by-Cory-Paulson Magnum Opus on Research] by Cory Paulson

Guide to Medicine

2024-04-21T01:07:37Z

Drulikar: Update Cryogenic Chambers for https://github.com/cmss13-devs/cmss13/pull/6058 and add anchors

=General Diagnostics=

==Damage Types==
{| class="mw-collapsible wikitable sortable"
! Damage Type:
! class = "unsortable"|Symptoms:
! class = "unsortable"|Possible cause:
! class = "unsortable"|Treatment:

|-
| style="text-align:center;" | [[File:Advanced_first-aid_kit.png]] {{Anchor|Brute}}[[#Brute|Brute]]
||
*Damaged body parts
*#Possibility of [[#Bleeding|bleeding]]
*#Possibility of [[#Fractures|breaking bones]]
*#Small chance of getting [[#Organ Damage|organ damage]]
*#*[[#Eye|Eye]]
*#*[[#Brain|Brain]]
*#*[[#Heart|Heart]]
*#*[[#Lung|Lung]]
*#*[[#Liver|Liver]]
*#*[[#Kidney|Kidney]]
*Moderate amount of [[#Pain|pain]]
||
*Gunfire
*Melee combat
*Explosives
*Peridaxon OD
||
*[[#Gauze|Roll of gauze]]
*[[#Advanced trauma kit|Advanced trauma kit]]
*[[Chemistry#Bicaridine|Bicaridine]]
*[[Chemistry#Tricordrazine|Tricordrazine]]
*[[#Cryogenic Chambers|Cryotube]]

|-
| style="text-align:center;" | [[File:Fire_first-aid_kit.png]]<br>{{Anchor|Burn}}[[#Burn|Burn]]||
* Burned body parts
* Large amount of [[#Pain|pain]]
||
*Fire
*Acid (example: xenomorph acid, unfiltered water on Trijent Dam)
*Electrocution
*Extreme Cold (example: snowstorms and bodies of water on Sorokyne Strata)
||
*[[#Ointment|Ointment]]
*[[#Advanced burn kit|Advanced burn kit]]
*[[Chemistry#Kelotane|Kelotane]]
*[[Chemistry#Dermaline|Dermaline]]
*[[Chemistry#Tricordrazine|Tricordrazine]]
*[[#Cryogenic Chambers|Cryotube]]

|-
| style="text-align:center;" | [[File:Toxinfirstaid.png]]<br>{{Anchor|Toxins}}[[#Toxins|Toxins]]||
*Periodical throwing up, followed up by being briefly stunned
*Nausea and dizziness
*Very large amounts of [[#Pain|pain]]
*Organ damage (if extremely high)
**[[#Liver|Liver]]
**[[#Kidney|Kidney]]
||
*Poisons/toxins
*Overdose of medicine (not every kind of overdose causes this)
*Heavy-extreme [[#Blood Loss|blood loss]]
*Chestbursting
*Organ damage
**[[#Liver|Liver]]
**[[#Kidney|Kidneys]]
*Digesting things that should not be digested (Poison, Alcohol)

*[[#Cryotubes|Cryotubes]] with no cryomix
||
*[[Chemistry#Dylovene|Dylovene]]
*[[Chemistry#Tricordrazine|Tricordrazine]]
*[[Surgery#Internal Organs Surgery|Surgery (if organs are damaged)]]
*[[#Cryogenic Chambers|Cryotube]]

|-
| style="text-align:center;" | [[File:Oxygen_deprivation_first_aid.png]]<br>{{Anchor|Suffocation}}[[#Suffocation|Suffocation]]||
*Gasping and/or coughing up blood
*Passing out at 50 damage
||
*Organ damage
**[[#Lung|Lung]]
**[[#Heart|Heart]]
*[[#Blood Loss|Blood loss]]
*[[#Hard Crit|Dying]]
||
*[[Chemistry#Dexalin|Dexalin]]
*[[Chemistry#Dexalin Plus|Dexalin+]]
*[[Chemistry#Inaprovaline|Inaprovaline]]
*[[Surgery#Internal Organs Surgery|Surgery (if organs are damaged)]]
*[[#Cryogenic Chambers|Cryotube]]
|-
| style="text-align:center;" | [[File:Radiation_first-aid_kit.png]]<br>{{Anchor|Genetic}}[[#Genetic|Genetic]]
||
*Being unable to use limbs if the damage's too high
*Lowered overall health
||
* Radiation.
||
*[[Chemistry#Ryetalyn|Ryetalyn]]
*[[#Cryogenic Chambers|Cryotube]]
|}

===Organ Damage===
{| class="mw-collapsible wikitable sortable"
!Damage Type:
! class = "unsortable"|Symptoms:
! class = "unsortable"|Possible cause:
!class = "unsortable"|Treatment:

|-
|{{Anchor|Brain}}[[#Brain|Brain]]||
*Dropping items out of your hands and resting randomly, rare random erratic movements
*Headaches
*Impaired vision
*Has no further effects, even beyond 100 damage
**Reads on the health analyzer as 'Patient is braindead'.
|
*[[#Brute|Brute]] head trauma
*Tricordrazine overdose
|
*[[Chemistry#Alkysine|Alkysine]]
*[[Surgery#Brain Damage Surgery|Surgery]]

|-
|{{Anchor|Eye}}[[#Eye|Eye]]||
*Blurry vision
*Blindness
|
*[[#Brute|Brute]] head trauma
*Welding without eye protection
*Screwdriver to the eyes
|
*[[Chemistry#Peridaxon|Peridaxon (Does not heal, '''ONLY''' stops negative effects of eye damage)]]
*[[Chemistry#Imidazoline|Imidazoline]]
*[[Surgery#Eye Surgery|Surgery]]

|-
|{{Anchor|Heart}}[[#Heart|Heart]]||
*Lowers effective [[#Blood Loss|blood level]] of the body, causing, at 100% blood:
**Small amount of [[#Suffocation|oxygen damage]] capped around 21, when heart is damaged
**Rapid amount of [[#Suffocation|oxygen damage]] until around 50, at 10 damage
***Rate of [[#Suffocation|oxygen damage]] slows significantly, but does not stop, after 50 damage
**Rapid amount of [[#Suffocation|oxygen damage]] and [[#Toxins|toxin damage]] and an inability to be revived, at 30 damage
***Also known as [[#Defibrillator icons|heartbreak]].
|
*Moving with an unsplinted [[#Fractures|fractured]] chest
*Armor piercing damage to chest
*Random chance upon receiving extreme [[#Brute|brute damage]] to the chest
*[[#Defibrillator Usage|Defibrillation attempts]]
|
*[[Chemistry#Peridaxon|Peridaxon (Does not heal, '''ONLY''' stops negative effects of heart damage)]]
*[[Surgery#Internal Organs Surgery|Surgery]]

|-
|{{Anchor|Lung}}[[#Lung|Lung]]||
*Reads as 'ruptured' on scanners
*Fast accumulation of [[#Suffocation|oxygen damage]] until death
*Coughing up blood
*Inability to breathe anesthetic during surgery (Use Oxycodone or Suxamorycin as anesthetic instead)
|
*Moving with an unsplinted [[#Fractures|fractured]] chest
*Armor piercing damage to the chest
*Random chance upon receiving extreme [[#Brute|brute damage]] to the chest
|
*[[Chemistry#Peridaxon|Peridaxon (Does not heal, '''ONLY''' stops negative effects of lung damage)]]
*[[Surgery#Internal Organs Surgery|Surgery]]

|-
|{{Anchor|Liver}}[[#Liver|Liver]]||
*Accumulation of [[#Toxins|toxin damage]] dependent upon amount of damage
*Alchohol and poison metabolises slower, and alchohol deals [[#Toxins|toxin damage]]
|
*Moving with an unsplinted [[#Fractures|fractured]] chest
*Armor piercing damage to the chest
*Random chance upon receiving extreme [[#Brute|brute damage]] to the chest
*Alcohol poisoning
*Extreme [[#Toxin|toxin damage]]
|
*[[Chemistry#Peridaxon|Peridaxon (Does not heal, '''ONLY''' stops negative effects of liver damage)]]
*[[Surgery#Internal Organs Surgery|Surgery]]

|-
|{{Anchor|Kidney}}[[#Kidney|Kidney]]||
*Accumulation of [[#Toxins|toxin damage]] dependent upon amount of damage
|
*Moving with an unsplinted [[#Fractures|fractured]] groin
*Armor piercing damage to the groin
*Random chance upon receiving extreme [[#Brute|brute damage]] to the groin
*Extreme [[#Toxin|toxin damage]]
|
*[[Chemistry#Peridaxon|Peridaxon (Does not heal, '''ONLY''' stops negative effects of kidney damage)]]
*[[Surgery#Internal Organs Surgery|Surgery]]
|}
<br>

==Other Medical Conditions==
{| class="mw-collapsible wikitable sortable"
!Medical Condition:
! class = "unsortable"|Symptoms:
! class = "unsortable"|Possible cause:
!class = "unsortable"|Treatment:

|-
|{{Anchor|Fractures}}[[#Fractures|Fractures]]||
*Moderate amount of pain
*Dropping items out of your hands randomly (arm or hand)
*Notable slowdown (leg or foot)
*Chance for Internal Bleeding to occur if patient moves with a unsplinted fracture.
*Organ damage in fractured region upon unsplinted movement (head, chest, and groin)
**'''Head'''
***[[#Eye|Eye]]
***[[#Brain|Brain]]
**'''Chest'''
***[[#Heart|Heart]]
***[[#Lung|Lung]]
***[[#Liver|Liver]]
**'''Groin'''
***[[#Kidney|Kidney]]
||
* Extreme [[#Brute|brute damage]]
**Approximately over 25 brute damage for limbs
**Approximately over 50 brute damage for head, chest, and groin
||
*[[#Splints|Splints (Does not heal, '''ONLY''' stops negative effects of broken bones)]]
*[[Surgery#Bone Repair Surgery|Surgery]]

|-
|{{Anchor|Blood Loss}}[[#Blood Loss|Blood Loss]]||
*Blurry vision
*[[#Suffocation|Oxygen damage]] capped around 21 (low blood)
**Gives the message 'You feel dizzy/woozy/faint'
*Fast buildup of [[#Suffocation|oxygen damage]] until death (critical blood)
**Gives the message 'You feel extremely dizzy/woozy/faint'
*Fast buildup of [[#Toxins|toxin damage]] until death (critical blood)
||
* [[#Bleeding|Bleeding]]
* [[#Internal Bleeding|Internal Bleeding]]
* Blood extraction
||
* Blood refill via [[#IV Drip|IV drip]] (preferably O- blood)
* Iron
* [[Chemistry#Nutriment|Nutriment]] (food or [[Chemistry#Sugar|sugar]])

|-
|{{Anchor|Bleeding}}[[#Bleeding|Bleeding]]||
* [[#Blood Loss|Loss of blood]] depending on the severity of the wound
**A cut with 5 [[#Brute|brute damage]] isn't worth bothering with, but a gash of 70 [[#Brute|brute damage]] will cause a lot of [[#Blood Loss|blood loss]]
||
* Certain sources of [[#Brute|brute damage]], such as knives
||
* [[#Advanced Trauma Kit|Advanced trauma kits]] to affected area and wait for it to fully heal.
* [[#Gauze|Roll of gauze]] to affected area to stop the bleeding.
* Waiting for the wound to clot once treated.

|-
|{{Anchor|Internal Bleeding}}[[#Internal Bleeding|Internal Bleeding]]||
*[[#Blood Loss|Loss of blood]] that worsens over time
||
* Random chance upon receiving extreme [[#Brute|brute damage]]
* Armor piercing attacks
* Chance to occur when patient moves with an unsplinted fracture
||
* [[Surgery#Internal Bleeding Surgery|Surgery]]


|-
|{{Anchor|Pain}}[[#Pain|Pain]]||
*Slowness dependent on level of pain
*Blurry vision and stuttering past distressing pain
*Occasional knockdown in severe pain and stun in horrible pain
*Minor [[#Suffocation|suffocation damage]] in severe and horrible pain
*Changes to character icon on right side of HUD
*#[[File:Pain_Tier_0.png]] - No pain
*#[[File:Pain_Tier_1.png]] - Mild pain
*#[[File:Pain_Tier_2.png]] - Discomforting pain
*#[[File:Pain_Tier_3.png]] - Moderate pain
*#[[File:Pain_Tier_4.png]] - Distressing pain
*#[[File:Pain_Tier_5.png]] - Severe pain (softcrit)
*#[[File:Pain_Tier_6.png]] - Horrible pain (paincrit)
||
* [[#Damage Types|Damage]]
** Note: [[#Toxins|'''Toxin damage''']] causes the most pain, [[#Burn|'''Burn''']] damage causes the second most pain, and [[#Suffocation|'''Oxygen damage]] causes no pain.
* [[#Fractures|Fractures]]
* Stun batons
* Pepper spray
* Tear gas
||
* Painkillers
**In order from most powerful to weakest:
**#[[Chemistry#Oxycodone|Oxycodone]]
**#[[Chemistry#Tramadol|Tramadol]]
**#[[Chemistry#Paracetamol|Paracetamol]]
**Overdosing on a painkiller will double the effect. Additionally, some patients may have an 'opiate receptor deficiency' and will only have 75% of the standard painkilling effect - but also only 75% of the overdose effect, barring oxygen damage.
* Using [[#Splints|splints]] on [[#Fractures|fractures]]
* Treating [[#Damage Types|damage]]

|-
|{{Anchor|Hard Crit}}[[#Hard Crit|Hard Crit]]||
*Unconsciousness
*[[#Suffocation|Oxygen damage]]
*Change to character icon on right side of HUD
**[[File:Pain_Tier_6.png]]
||
* Accumulating an extreme amount of damage
||
* Treating [[#Damage Types|damage]]

|-
|{{Anchor|Missing Limb/Decapitation}}[[#Missing Limb/Decapitation|Missing Limb/Decapitation]]||
*Massive amount of pain
*Inability to use a hand (arm or hand)
*Severe slowdown (leg or foot)
*Instant death (head) and braindeath (humans only)
||
* Extreme [[#Brute|brute damage]] for limbs and head (head only applies users without helmets unless the user is attacking with very sharp weapons).
* [[Surgery#Amputation|Amputation]]
||
*[[Surgery#Limb Replacement Surgery|Surgery]]
** [[Surgery#Synthetic Head Re-Attachment Surgery|Head-reattachment]] (for synthetic units)

|-
|{{Anchor|Shrapnel and Foreign Objects}}[[#Shrapnel and Foreign Object|Shrapnel and Foreign Objects]]||
*[[#Organ Damage|Organ damage]] upon reception
*[[#Brute|Brute damage]] upon reception
*[[#Brute|Brute damage]] upon unsplinted movement
||
* Gunfire
* Thrown sharp objects
||
*Yanking out an object (Only if object is externally embedded)
#Right click person
#Click '''Yank out object'''
*Remove with a knife by '''activating''' it (default hotkey: "{{Key press|Z}}").
*[[Surgery#Foreign Object/Alien Embryo Removal|Surgery]] can remove objects, but only if the object in question is deeply embedded or too small to remove with a regular knife.
* Click on others '''in help intent and surgery mode active''' with a knife in hand to remove shrapnel from them. Note that only those with medical skills get access to surgery mode.

|-
|{{Anchor|Alien Infection}}[[#Alien Infection|Alien Infection]]||
*Development of [[Larva|Alien larva]]
*Uncontrollable shaking near or upon [[Aliens|larva's]] full development
*Sore throats
*Coughing
*Sneezing
*Mucus generation
||
* Infection via an alien egg, [[Carrier|carrier]], [[Carrier|carrier hugger trap]], [[Drone|drone]], [[Queen|queen]], or [[Hivelord|hivelord]]
||
*[[Surgery#Foreign Object/Alien Embryo Removal|Surgery]]
|}

==Medicine==
===Autoinjectors===
<center>
Most auto injectors have 3 uses in each of them. Each injection will induce half of the overdose threshold of their chemical, so be cautious when injecting more than their overdose limits.
</center>
{| class="wikitable"
!Autoinjector Type:
!What it does:
!Dosage:
!Overdose:
|-
|{{Anchor|Emergency Auto-injector}}[[File:Emergency_Auto_injector.png|64px]]<br>'''Emergency Auto-injector'''
|An auto-injector loaded with a special cocktail of chemicals, to be used in a life-threatening situations. Contains 29 units of [[Chemistry#Bicaridine|bicaridine]], 29 units of [[Chemistry#Kelotane|kelotane]] and 19 units of [[Chemistry#Oxycodone|oxycodone]].
| 77 units
| Additional chemicals listed in its contents.
|-
|{{Anchor|Bicaridine Autoinjector}}[[File:Bicaridine.png|64px]]<br>[[Chemistry#Bicaridine|'''Bicaridine''']]
|Heals [[#Brute|brute damage]], faster than [[#Tricordrazine Autoinjector|tricordrazine]]. Overdose causes [[#Burn|burn damage]] first, and then [[#Toxin|toxin damage]].
| 15 units
| 30 units
|-
|{{Anchor|Tramadol Autoinjector}}[[File:Tramadol_Injector.png|64px]]<br>[[Chemistry#Tramadol|'''Tramadol''']]
|Standard issue painkiller of moderate strength, used to keep marines from paincrit, pain slowdown or whining about broken bones. Overdose causes [[#Toxin|toxin damage]].
| 15 units
| 30 units
|-
|{{Anchor|Pain-Stop Autoinjector}}[[File:Tramadol_Injector.png|64px]]<br>[[Chemistry#Tramadol|'''Pain-Stop''']]
|A version of the [[#Tramadol Autoinjector|Tramadol autoinjector]] that can be used by everyone. Found in First-Aid pouches and NanoMed dispensers. Overdose causes [[#Toxin|toxin damage]].
| 15 units
| 30 units
|-
|{{Anchor|Tricordrazine Autoinjector}}[[File:Tricord.png|64px]]<br>[[Chemistry#Tricordrazine|'''Tricordrazine''']]
|Heals [[#Toxin|toxin]], [[#Burn|burn]], [[#Brute|brute]] and [[#Suffocation|oxy damage]], albeit quite slowly. Overdose causes [[#Brain|brain]], [[#Toxin|toxin]], [[#Burn|burn]], and [[#Brute|brute damage]].
| 15 units
| 30 units
|-
|{{Anchor|First-Aid Autoinjector}}[[File:Tricord.png|64px]]<br>[[Chemistry#Tricordrazine|'''First-Aid''']]
|A version of the [[#Tricordrazine Autoinjector|Tricordrazine autoinjector]] that can be used by everyone. Found in First-Aid pouches and NanoMed dispensers. Overdose causes [[#Brain|brain]], [[#Toxin|toxin]], [[#Burn|burn]], and [[#Brute|brute damage]].
| 15 units
| 30 units
|-
|{{Anchor|Dexalin+ Autoinjector}}[[File:Dexalin.png|64px]]<br>[[Chemistry#Dexalin Plus|'''Dexalin+''']]
|Instantly heals all [[#Suffocation|respiration damage]]. Overdose causes [[#Toxin|toxin damage]].
| 1 unit
| 15 units
|-
|{{Anchor|Kelotane Autoinjector}}[[File:Kelotane.png|64px]]<br>[[Chemistry#Kelotane|'''Kelotane''']]
|Heals [[#Burn|burn damage]]. Overdose causes [[#Brute|brute]] and [[#Toxin|toxin damage]].
| 15 units
| 30 units
|-
|{{Anchor|Dylovene Autoinjector}}[[File:Dylovene.png|64px]]<br>[[Chemistry#Dylovene|'''Dylovene''']]
||Heals [[#Toxin|toxin damage]] Overdose causes [[#Eye|blindness]].
| 15 units
| 30 units
|-
|{{Anchor|Inaprovaline Autoinjector}}[[File:Inaprovaline.png|64px]]<br>[[Chemistry#Inaprovaline|'''Inaprovaline''']]
|Stabilizes critical patients, slowing down their [[#Suffocation|oxygen damage]] buildup. Also acts like a weak painkiller. Overdose causes heart damage.
| 15 units
| 60 units
|-
|{{Anchor|Adrenaline Autoinjector}}[[File:Epinephrine-Injector.png|64px]]<br>[[Chemistry#Epinephrine|'''Epinephrine''']]
|An autoinjector loaded with 10 units of Epinephrine, better known as Adrenaline, a nerve stimulant useful in restarting the heart.
| 10 units
| +10 units
|-
|{{Anchor|Oxycodone Autoinjector}}[[File:Oxycodone.png|64px]]<br>[[Chemistry#Oxycodone|'''Oxycodone''']]
|Very robust painkiller, practically making all of your pain go away - metabolizes fairly quickly, though. Very useful as anesthetic as well. Overdose causes hallucinations and [[#Toxin|toxin damage]].
| 10 units
| 20 units
|}

'''Remember that you can restock your autoinjectors, so don't just throw them away. Put them back into your belt instead, they can be refilled at the WeylandMed vendors - just click on them to refill the injector if you have access to them. They don't need to be empty in order to be refilled - simply left click the vendor with a non-full injector in your active hand.'''
<br><br>

===Pill Bottles[[File:PillBottle.png|64px]]===
*'''You can hover over a pill bottle and see at a glance what chemicals the pill bottle contains by looking at the bottom left of your game window or by remembering the color code the pill bottle has.'''

*'''Pill bottles from vendors and lifesaver bags have a fixed color for the pill bottles and pills every round. However, if a pill bottle comes from chemistry, you will need to refer to both the label name for the pill bottle and the examined contents of the pills inside.'''

''Other pill bottles exist but have the same dosage and OD listed in the [[#Autoinjectors | autoinjector]] section. Unless they are custom made from chemistry.''

{| class="wikitable"
!Item:
!What it does:
!Dosage:
!Overdose:
|-
|Tramadol
||Standard issue painkiller of moderate strength, used to keep marines from paincrit, pain slowdown or whining about broken bones. Overdose causes toxin damage.
||15 Units
||30 Units
|-
|Peridaxon
||Stops most symptoms from Organ damage but does not fix them. Available from marine medical vendors. Overdose causes brute damage.
||10 Units
||15 Units
|-
|Dexalin
||Removes oxygen damage at a moderate rate. Overdose causes toxin damage.
||15 Units
||30 Units
|-
|Russian Red
||Removes radiation and causes Brute damage every cycle. (Note: currently disabled and should not appear during normal gameplay.)
||10 Units
||10 Units
|}
'''Note: Dosages are for pills found in MarineMed vendors, medics' Automated Equipment Racks, [[Marine Equipment#M276 Pattern Lifesaver Bag|Lifesaver Bags]], and the [[Requisitions#Medical crate|Requisitions medical crate]]'''.
<br>

===First Aid Kits===
{| class="wikitable"
!Item:
!|What it contains:
|-
|{{Anchor|Basic first aid kit}}[[File:Firstaid.png|64px]]<br>'''Basic first aid kit'''||
*1 [[#Health Analyzer|Health analyzer]] [[File:Healthanalyzer.png|32px]]
*1 [[#First-aid Autoinjector|First-aid autoinjector]] [[File:Tricord.png|32px]]
*1 [[#Pain-stop Autoinjector|Pain-stop Autoinjector]] [[File:Tramadol_Injector.png|32px]]
*1 [[#Inaprovaline Autoinjector|Inaprovaline Autoinjector]] [[File:Inaprovaline.png|32px]]
*1 [[#Gauze|Rolls of gauze]] [[File:Gauze.png|32px]]
*1 [[#Ointment|Ointments]] [[File:Ointment.png|32px]]
*[[#Splints|Splints]] [[File:Splint.png|32px]]
|-
|{{Anchor|Advanced first aid kit}}[[File:Advfirstaid.png|64px]]<br>'''Advanced first aid kit'''||
*1 [[#Tricordrazine Autoinjector|Tricordrazine autoinjector]] [[File:Tricord.png|32px]]
*3 [[#Advanced Trauma Kit|Advanced trauma kits]] [[File:Advtraumakit.png|32px]]
*2 [[#Advanced Burn Kit|Advanced burn kits]] [[File:Advburnkit.png|32px]]
*[[#Splints|Splints]] [[File:Splint.png|32px]]
|-
|{{Anchor|Fire first aid kit}}[[File:Firefirstaid.png|64px]]<br>'''Fire first aid kit'''||
*1 [[#Health Analzyer|Health analyzer]] [[File:Healthanalyzer.png|32px]]
*2 [[#Ointment|Ointments]] [[File:Ointment.png|32px]]
*3 [[#Kelotane Autoinjector|Kelotane Autoinjector]] [[File:Kelotane.png|32px]]
*1 [[#Pain-stop Autoinjector|Pain-stop Autoinjector]] [[File:Tramadol_Injector.png|32px]]
|-
|{{Anchor|Oxygen deprivation first aid kit}}[[File:Oxyfirstaid.png|64px]]<br>'''Oxygen deprivation first aid kit'''||
*1 [[#Health Analzyer|Health analyzer]] [[File:Healthanalyzer.png|32px]]
*2 [[Chemistry#Dexalin|Dexalin]] pills (15 units)
*3 [[#Dexalin+ Autoinjector|Dexalin+ autoinjector]] [[File:Dexalin.png|32px]]
*1 [[#Inaprovaline Autoinjector|Inaprovaline Autoinjector]] [[File:Inaprovaline.png|32px]]
|-
|{{Anchor|Toxin first aid kit}}[[File:Toxinfirstaid.png|64px]]<br>'''Toxin first aid kit'''||
*1 [[#Health Analzyer|Health analyzer]] [[File:Healthanalyzer.png|32px]]
*3 [[#Dylovene Autoinjector|Dylovene Autoinjector]] [[File:Dylovene.png|32px]]
*3 [[Chemistry#Dylovene|Dylovene]] pills (15 units)

|-
|{{Anchor|Radiation first aid kit}}[[File:radiation first-aid kit.png|64px]]<br>'''Radiation first aid kit'''||
*4 Russian Red pills
*2 [[#Bicaridine Autoinjector|Bicaridine autoinjectors]] [[File:Bicaridine.png|32px]]
|}
<br>

===Equipment===
{| class="wikitable"
!Item:
!What it does:
|-
||{{Anchor|Health Analyzer}}[[File:Healthanalyzer.png|64px]]<br>'''Health Analyzer'''
||Basic tool of every single medic - this miraculous item allows you to see the patient's status, showing the damage, bleeding, internal bleeding and broken bones. Keep in mind that this toy won't show you which bones are broken unless it's a limb. Don't leave your home without it. You can also scan a patient's vitals through a stasis bag by just clicking on the stasis bag with the analyzer in hand.
*You can swap between two hud modes by right clicking the health analyzer and selecting '''"Switch Hud"'''. The default mode displays the analyzers results in a pop up window, the second hud mode displays the results in the chat.
*Restockable to NanoMed[[File:NanoMed.png]] (drag it to the NanoMed)
|-
||{{Anchor|HealthMate HUD}}[[File:MedicHud.png|64px]]<br>'''HealthMate HUD'''
|| {{Sensormate_Description}} If there is no health bar it means that the patient is at 100% health. The Healthmate Hud also allows you to add holographic cards onto marines you examine for triage purposes (same way that you mark criminals as 'wanted' with security HUD glasses). '''Scan reports are stored in the patient's medical records once viewed in the scanner console, when you wear a HealthMate HUD you can view their latest scan report by examining them.'''
|-
||{{Anchor|Gauze}}[[File:Gauze.png|64px]]<br>'''Gauze'''
||Basic gauze used to stop the bleeding and fix brute trauma over time.

*Restockable to NanoMed[[File:NanoMed.png]] (drag it to the NanoMed)
|-
||{{Anchor|Ointment}}[[File:Ointment.png|64px]]<br>'''Ointment'''
||Basic burn treatment item that heals 5 burn damage once applied and fixes it over time.

*Restockable to NanoMed[[File:NanoMed.png]] (drag it to the NanoMed)
|-
||{{Anchor|Advanced Trauma Kit}}[[File:Advtraumakit.png|64px]]<br>'''Advanced Trauma Kit'''
||Used to treat moderate to high brute damage. Heals 12 brute damage once applied and fixes it over time. The time spent of using the trauma kit and efficiency depends of one's medical skill.
|-
||{{Anchor|Advanced Burn Kit}}[[File:Advburnkit.png|64px]]<br>'''Advanced Burn Kit'''
|| Used to treat moderate to high burn damage. Heals 12 burn damage once applied and fixes it over time. The time spent of using the burn kit depends of one's medical skill.
|-
||{{Anchor|Splints}}[[File:Splint.png|64px]]<br>'''Splints'''
||Used to hold that broken/fractured bone of yours in place so you don't die. The time spent of using the splints depends of one's medical skill.
*Restockable to NanoMed[[File:NanoMed.png]] (drag it to the NanoMed)
|-
||{{Anchor|Hypospray}}[[File:Hypospray.png|64px]]<br>'''Hypospray'''
|| An experimental high-end chemical injector, used for instant injections. Holds 30 units. Injects 5 units per use. Can be empty or preloaded with Tricordrazine. Can dissolve pills into. Can be unlocked using a screwdriver or the 'Unlock Hypospray' verb, to allow the vial capsule to be ejected like a magazine.
|-
||{{Anchor|Emergency Defibrillator}}[[File:Defibrillator.png|64px]]<br>'''Emergency Defibrillator'''
|| Used to bring recently dead marines and other personnel back to life. Can be recharged in a special recharger (usually located in the medbay)
*Starts with 15 charges and goes yellow when 5 charges are left. The availability of the defibrillator's usage depends of one's medical skill.
|-
||{{Anchor|Stasis Bag}}[[File:StasisBag.png|64px]]<br>'''Stasis Bag'''
||Used to store critically injured patients.
*Slows larva growth.
*Patients can be scanned without opening the bag and be put into advanced scanners and onto operating tables without opening the bag.To do this, grab the stasis bag then click on the advanced scanner/operating table to deploy the patient.
*Prevents blood loss while the patients are inside
*Prevents internal bleeding from progressing as long as they are left inside.
*Halts metabolisation of chemicals.

*'''Can be buckled to a roller bed for faster transportation.'''
*To fold it, drag it to yourself when it's closed and not occupied
|-
||{{Anchor|Body Bag}}[[File:BodyBag.png|64px]]<br>'''Body Bag'''
|| Used to store your recently dead comrades.
*If you use a pen on a body bag you can name the body bag and on the body bag sprite a dogtag will appear. (Useful for naming the body bag so players know who's inside it.)

*'''Can be buckled to a roller bed for faster transportation.'''
*To fold it, drag it to yourself when it's closed and not occupied
|-
||{{Anchor|Syringe}}[[File:Syringe.png|64px]]<br>'''Syringe'''
|| Used to inject marines and other personnel with ungodly chemicals, or as a ghetto IV drip. Can instantly inject (At the cost of some brute damage, and a broken syringe.) if used on harm intent.
|-
||{{Anchor|Syringe Case}}[[File:SyringeCase.png|64px]]<br>'''Syringe Case'''
|| Used to store syringes and syringe bottles. Contains 3 slots.
|-
||{{Anchor|Roller Bed}}[[File:RollerBed.png|64px]]<br>'''Roller Bed'''
|| Allows you to quickly transport injured marines and other personnel across the battlefield. Can be folded up when not in use.
*Bad for performing surgery, but better than nothing
*You can attach a body bag or a stasis bag onto a roller bed for faster transportation
*To fold it, drag it to yourself when not occupied
|-
||{{Anchor|Med Evac Stretcher}}[[File:Med_Evac_Stretcher.png|64px]]<br>'''Med Evac Stretcher'''
|| Used to airlift patients to a supporting dropship. Functions in the same way as a roller bed but cannot be moved when deployed. To activate the med evac beacon on the stretcher (Right click the stretcher then click "Activate Medevac". '''Only medics (or marine personnel with equal or higher medical skill) can activate the beacon and it can only be used outdoors or if the ceiling is glass (examine the tile to check.).''').
*Utterly useless for performing surgery
*You can attach a body bag or a stasis bag onto the stretcher
*To fold it, drag it to yourself when it's not occupied
|-
||{{Anchor|Portable Surgical Bed}}[[File:FieldSurgicalBed.png|64px]]<br>'''Portable Surgical Bed'''
|| A collapsible bed used for field surgery. Functions in the same way as a roller bed but cannot be moved when deployed.
*Excellent for performing surgery, second only to a proper operating table
*To fold it, drag it to yourself when it's not occupied
|-
||{{Anchor|IV Drip}}[[File:IVdrip.png|64px]]<br>'''IV Drip'''
|| Allows you to inject blood into a patient or extract blood from them to do a blood transfusion.
*Can be fitted with a beaker to inject chemical solutions automatically.
|-
||{{Anchor|Blood Bag}}[[File:BloodPack.png|64px]]<br>'''Blood Bag'''
|| Holds blood inside of it. Make sure [[#Blood Compatibility|the blood type's compatible]] with the recipient.
|-
||{{Anchor|Surgical Line}}[[File:Surgical Line.png|64px]]<br>'''Surgical Line'''
|| A roll of military-grade surgical line, able to seamlessly seal and tend any wound. Also works as a robust fishing line for maritime deployments.
|}

=Medical Contraptions=

{| class="wikitable"
|-
! Name !! Description
|-
| [[File:Cryo.gif]] Cryogenic Chambers{{Anchor|Cryogenic Chambers}}||
*Used for putting critical patients into stasis and treating patients with genetic damage. Be sure to check periodically to see if the chambers need to be restocked with chemicals and if your patient is sufficiently healed. The tubes can auto-eject patients once they're completely healed.

*The extreme cold of the cryotube will give patients a slight (single-digit) amount of burn damage.

* Cryogenic chambers will slow the development of alien larva/embryos. You can use one of these just like you could use a stasis bag if you cannot immediately tend to a patient with a larva.

*Additionally when [[Chemistry#cryoxadone|Cryoxadone]] or [[Chemistry#clonexadone|Clonexadone]] are used, internal bleeding will be cured and chemicals are allowed to process in the dead.

{| class="mw-collapsible mw-collapsed wikitable"
! colspan="2" | Setting up Cryo  
|-
|
#Take a nearby [[File:Beaker.png]] beaker filled with appropriate medicine, for example the two [[Chemistry#cryoxadone|Cryoxadone]] small beakers in the Chemistry Station, then click on the cryo cell to load the beaker in.
#Set the cryotube to On.

While [[Chemistry#clonexadone|Clonexadone]] is a fairly efficient medical chem (and [[Chemistry#cryoxadone|Cryoxadone]] to a much lesser extent), consider using a larger, 120u beaker, and adding additional useful chems, like [[Chemistry#nutriment|Nutriment]], [[Chemistry#alkysine|Alkysine]], [[Chemistry#imidazoline|Imidazoline]], [[Chemistry#dermaline|Dermaline]] etc. to heal even more types of damage (or to simply stack healing effects with Cryoxadone/Clonexadone) at once, beyond what the standard cryotube chemicals can do.
|}
|-
| [[File:Sleeper.gif]][[File:Console.gif]] Sleepers{{Anchor|Sleepers}}|| To put a patient inside the sleeper use grab intent and click on the patient then the sleeper. To take out the patient right click the sleeper then click Eject Occupant.
*Sleepers are used to administer medication and perform dialysis.

*The sleepers will not stabilize critical patients, though they can be used to administer inaprovaline.

*Dialysis: Once the patient is inside, click 'Start Dialysis'. Dialysis filters out blood, having the bonus of pulling out chemicals. This treatment should be used when you believe someone to be overdosing or to be poisoned. The beaker inside the sleeper will fill with the blood and eventually you will need to empty it. To retrieve the beaker, right-click on the sleeper and click 'eject beaker'. Dialysis can cause a patient to suffer from severe blood loss if the patient is left in too long.
|-
| [[File:Advbodyscanner.gif]][[File:Advbodyscanner_console.gif]] Advanced Body Scanner{{Anchor|Advanced Body Scanner}}|| To put a patient inside the body scanner use grab intent and click on the patient then the body scanner. To take out the patient right click the body scanner then click Eject Occupant.
*The Body scanner is mainly used to locate broken bones, organ damage, shrapnel, and any unwanted guests in your stomach.

*Use the console to interact with the body scanner, this allows you to print out a report to send along with the patient to surgery which will help the surgeon. Additionally, there will be a scan report that is attached to the person you've scanned when you examine them.
|-
| [[File:AutoDoc.png|32px]] AutoDoc{{Anchor|AutoDoc}}|| The AutoDoc is an extremely useful machine in medical that can automatically fix a marine with any number of injuries, just be aware that it cannot perform larva removal. To learn more about the AutoDoc and it's features head [[Surgery#The_Autodoc_System|'''here''']].
|-
|}

=Medical Procedures=
==CPR==
CPR will keep someone in hard crit (>150 damage) alive by reducing their oxy damage. If you notice a marine or other personnel gasping and on the floor, they may require CPR, otherwise, they will reach 200 damage in total and suffocate.
#First you'll want to set your intent to help.
#Make sure you aren't wearing a mask.
#Have an empty hand.
#Click on the gasping injured player.
#If you start shaking them, they don't have enough oxygen damage to permit the use of CPR.
#Once you start doing CPR keep doing it until you can get them to a safe location or to a medic.
#CPR can also extend the timer of dead marines that are still revivable. The default time a marine has after death is 5 minutes before becoming clinically declared dead. (Permanent death)
#If the person you are CPRing is deceased, doing CPR requires 4 seconds and adds 7 seconds to the dead marine's defibbable status timer. You have to wait between CPR pumps at least 3 seconds or else the CPR fails. If you fail a CPR pump due to pumping too quickly, you must still wait at least the full 3 seconds before you can attempt another successful CPR pump. Failing CPR does not increase the time the person has before they become permanently dead.

Pro tip you can grab them in one hand and do CPR with the other.
<br><br>

Notes:
*Shipside roles such as nurse, doctor, researcher, and CMO, have high medical skill and require only three seconds to CPR. Count to four seconds if you are performing CPR on a deceased marine as one of these roles.
*Moving will interrupt CPR. Switching hands while the CPR is winding up will *not* interrupt CPR. You can administer medication while performing CPR.

==Procedure for Reviving Non-Breathing Patients[[File:Defibrillator.png]]==
#Locate non-breathing patient with a green/orange heart rate icon next to their health bar (Only visible if wearing the healthmate HUD). [[File:Resuscitation_LightningBolt_Icon.png|64px]]
#Scan the patient with a health analyzer.
#If the sum of the patient's brute, burn, oxygen, and toxins damage is less than 200, proceed to strip armor and defibrillate. Recognize that oxygen damage can be ignored if you plan on using epinephrine. Otherwise, apply trauma and burn kits to all untreated parts of the patient's body. Pro tip: Using your numpad keys allows you to quickly cycle through limbs to decrease the total time required to kit them.
#Scan the patient again. If the sum of the patient's summed damage is less than 200, proceed to strip armor and defibrillate. Otherwise, consider performing tend wounds surgery. Remember that tend wounds with surgical line repairs 10 damage every 2 seconds, or 300 damage per minute if uninterrupted. If you can bring their damage under 200 damage with tend wounds before the patient's revival timer expires, proceed to tend wounds. Otherwise, apply CPR while asking nearby medics and marines to perform CPR on the patient while you perform tend wounds surgery. One marine is enough for CPR. If there are extra medics available ask them to tend wounds along with you. If there are no marines nearby, consider pulling the patient to marines that can perform CPR. Once someone is performing CPR, continue on to tend wounds.
#Tend wounds (Target an area of the body of the patient that has the highest amount of brute and burn damage. Use surgical line for brute and synthgraft for burns. Hold the surgical line in your hand and click the patient with the help intent and surgery intent enabled). The surgery will repeat until no more burn or brute damage can be resolved upon that limb, upon which you may target another area of the body and repeat. Scan periodically with a health analyzer to keep an eye on the patient's summed damage. Repeat until you run out of limbs to treat or summed brute and burn damage drop below 200.
#Strip armor of the patient. (Click-drag the patient to your character and select the armor in their armor slot. Do not move or switch hands until the wind-up has elapsed or stripping will cancel)
#Apply the defibrillator. Take the defibrillator out of your bag, press Z while the defibrillator is in your active hand to pop the handles out of their housing, and click the patient. If you are successful, after seven seconds of windup chimes the defibrillator will shock your patient and revive them. Do not move while the windup is occurring, or the defibrillation will cancel. While the defibrillator is winding up, you may swap to your other hand and begin feeding the patient pills or applying auto injectors. Repeat defibrillation until the patient has been revived. (Toggling belt mode on your medical belt to remove pills directly from bottles on click or middle clicking to open pill bottles without having them in your hand may help with this).
#Continue to treat the patient until they are stable.
#You can also apply necessary medicine BEFORE resuscitation but it will not be metabolized until the patient is living again. (You can give inaprovaline before reviving to stabilize them after they are resuscitated.)
#'''RECOMMENDED:''' If available, inject epinephrine (use Hypospray/Syringe) into the patient before defibrillating. This will greatly enhance the amount you heal per each attempt, in addition to clearing all oxygen damage on revival. ([12 + 16 brute and 16 burns] healed damage instead of [12 + 4 brute and 4 burns]). Note that epinephrine and inaprovaline are present in revival mixture available in squad medic preparation vendors.
#If you see a marine with an orange line on your HUD that has a lot of damage when scanned, ask a nearby marine to "CPR!" if any are in the vicinity.
#And please, don't ever give up if you see someone with over 200 damage. You can use advanced trauma and burn kits while defibbing with your other hand. You can also inject epinephrine while defibbing. Don't give up. Keep going. Save that marine!
<br>
=== Revival icons ===
If the icon has a red square around it when it is still green/yellow/orange, that means the client of the dead player has disconnected. It is still possible for them to come back.
{| class="wikitable"
! Icon !! Description
|-
| [[File:DNR_LightningBolt_Icon.png|128px]] || The red flatline icon states they have voluntarily opted out of being revived, and or their client has been disconnected. This can also be because the player was banned while they were dead. This is commonly referred to as "DNR, or Do Not Resuscitate, or dead dead".
|-
| [[File:Resuscitation_LightningBolt_Icon.png|128px]] || The green heart rate icon states they are revivable and have 5 minutes to be resuscitated (assuming no CPR is applied).
|-
| [[File:huddeadclose.png|128px]] || The solid yellow heart rate indicates some time has passed since they were last breathing and they are coming closer to becoming unrevivable.
|-
| [[File:Almostdeadframe1.png|128px]] [[File:Almostdeadframe2.png]] || The flashing orange and red heart rate indicates their defib timer has almost expired. If you see it going from solid yellow to flashing orange and red, it means the marine has exactly 1 minute left unless being CPR'd to increase their defib timer.
|-
| [[File:Broken_Heart_defib_icon.gif|128px]] || The broken heart indicates that the patient's heart has suffered too much trauma for revival attempts. This is known as heartbreak. The message will say: "Patient's general condition does not allow reviving." To fix this, a doctor must repair their heart in time before any further revival attempts are under taken. If a doctor is not immediately available, peform CPR on the corpse to extend their defib timer until a doctor can peform surgery to repair the heart.
|-
| [[File:skull_Icon.png|128px]] || The skull icon indicates they are not able to be revived.
|-
|}

===Lost Causes===
'''Don't try to defib any of the following corpses:'''
*Chestbursted personnel [[File:Bursted_marine.png]]
*Decapitated personnel [[File:Decapped_marine.png]]
*If you receive the message "Patient is braindead" or "Patient is DNR" from the [[#Emergency Defibrillator|defibrillator]] when you try to defib them.
<br>
*If you receive the message "Their eyes are blank and there are no signs of life" when you check their status (stand adjacent to the subject, right click their sprite, and select Check-status).

===Defibrillator Tips===
*'''If someone is brought back to life with a defib then die immediately afterwards, their death timer is reset.'''

*'''Defibrillators have a 25% chance of dealing 5 heart damage each time a shock is successfully applied. This is significant, as heart damage between 1 and 10 reduces effective blood volume by 80%, which, in turn, assuming the marine has full blood, will cause 20 oxygen damage on its own. Try to keep the patient alive after first defibrillation to minimize heart damage dealt. If at all possible when reducing damage in preparation for revival, prefer to apply brute and burn kits and suture over repeated defibrillations, as both methods reduce damage at a higher rate than defibrillating and do not incur heart damage.

*'''Your patients won't get their items back on by themselves the majority of the time. If you can, redress them.'''

*'''Switching hands while using a defibrillator will ''NOT CANCEL'' its use. You're able to operate the defibrillator while using another item in your off hand.'''

*'''Performing CPR on a patient will extend the defib time if done no often than once every 10 seconds.'''

*The only time a defibrillator loses charge is when its windup is completed and the shock is applied. There is also a brief delay after activating one before you can use it.

*If "Vitals signs are weak" is displayed it means that their combined brute/burn damage is over 200, keep using the defibrillator to lower that damage if you've already applied trauma and burn kits.

*Alternatively, it means that they've left their body and won't return if the combined damage is now below 200. Examine the corpse and if it says "Soul is departed" then give them ten to twenty seconds before defibbing again. If you get it again, then the player doesn't want to be revived.
<br>

==Synthetic Maintenance==
*To revive a dead synthetic use a defib on them. Synthetics need to have their head attached to their torso and have combined total damage below 200 points. Defibs do not repair damage on dead synthetics like they do on humans, you must repair the excess damage first.
*To fix brute damage on a synths body use a blowtorch on help intent.
*To fix burn damage on a synths body use cable coil.
*To fix heart/brain damage, apply nanopaste to that bodypart (head/chest)
<br>

==Overdose Treatment==
===Dialysis===

#Put your patient into a sleeper. [[File:Sleeper.gif]][[File:Console.gif]]
#Make sure it has a non-full, preferably empty beaker inside of it.
#Select "Start dialysis" option below the injections and wait few moments.
#Eject the patient and scan him just to notice his blood's clean.
Keep in mind that dialysis is a process that takes time, the chems won't flush out immediately.

'''<big>CPR</big>'''

# Only applicable in most cases if the patient was OD'd after death, during treatment
# CPR the dead patient to metabolize chems in the body
# Scan to make sure chems are below OD
# Revive

This is only applicable if the patient was not alive during their overdose, and was OD'd when death during treatment pre-revival. Major overdoses should still be used with Dialysis as perma timer will be accelerated with excessive CPR.

==Blood Transfusions==
By Blood Bag
*Select a blood bag (standard issue for Corpsmen)
*Ensure it is of a compatible blood type to the patient, Corpsmen issued Blood Bags are universal blood types.
*While standing next to the patient, click them with the bag
*The bag will now begin transfusing into the patient.
*When you are finished, click the patient with the bag to disconnect them.

By IV Stand
*Ensure a blood bag of compatible blood type is loaded into the IV stand. (You can unload a blood bag from an IV stand by clicking on the stand with an empty hand to check its blood bag if it is already loaded. Otherwise, you can load a bag into an IV stand by clicking it while the bag is in your active hand).
*Move the IV so that it is adjacent to your patient. (control click the IV stand to grab it. Then to move the stand, either move your character to pull the stand behind you or twice-click a tile adjacent to the stand to move the stand to that tile while the hand with the "UP-GRADE" sprite representing your grasp on the IV is active)
*Insert the IV into your patient's arm (click-drag the IV stand to your patient. No need to target the arm.)
*Your patient can move freely in a 7-tile wide square centered on the IV stand with the IV remaining in their arm.
*When you are satisfied with the amount of blood that has been transferred, remove the IV from the patient's arm (click-drag the IV stand to your patient again).
By Syringe
*Ensure you have a blood bag with blood compatible with the human you are transferring blood to. If it is O- blood, it is safely transfusable to humans with any blood type.
*Ensure the syringe is empty by verifying the interior of the syringe is colored black and there is green text underneath that says "DRAW".
*With the syringe in your active hand, click the blood bag three times to draw 15u of blood. The interior of the syringe will be colored red and there should be orange text underneath that says "INJECT".
*With the syringe in your hand click the human you wish to transfer blood to three times to transfer 15u of blood. '''Ensure harm intent is not enabled. If harm intent is enabled the syringe will break.''' If the target human is yourself, the blood will be transferred instantly. If the target human is not you, there will be a short windup before the blood will be transferred. You do not need to wait for the windup for the transfer of the first 5u of blood to complete before clicking again to initiate the windup for the transfer of the second and third 5u of blood.
*Repeat this process until you are satisfied with the amount of blood transferred
Additional information
*Alternately you can extract blood from a human if they have the right blood type by hooking them up to an IV with an empty blood pack or by using an empty syringe on them.
*Even after you've transfused blood into your patient, if they have been lacking blood for a while they are likely hungry. Ask them to eat!
*Not being too hungry enables you to regenerate blood. If you do not have access to blood transfusion or hemogenic iron generating drugs, advise your patient to eat food.
*Iron has the hemogenic trait, meaning when this reagent is in your system it regenerates blood volume.
*Sugar reduces a patient's hunger, enabling them to naturally regenerate blood slowly over time.
*Iron pills or combination iron-sugar pills are available aboard the Almayer from the pharmacy in medbay lower decks or from the Research pharmacy in medbay upper decks. Take advantage!
*Remember that in a pinch, hot cocoa also provides nutriments similar to food, and that flasks filled with hot cocoa, MRE's, protein bars, and vendor meals can all fit compactly into a med kit and are generally available to all roles!
<br>
===Blood Compatibility===
[[File:Bloodtypes_table.jpg]]
<br><br>

=General Tips=

*The cryo cells loaded with cyroxadone can slowly heal internal bleeding, depending on the severity of it. Clonexadone heals internal bleeding as well, but faster.

= Community guides and tutorials =
[https://www.youtube.com/watch?v=py5JJjGlhO0 Medical Tutorial] - By C4xmaniac, George Franks/Virgil

Chemistry

2024-04-21T01:07:06Z

Drulikar: fix nutriment anchor

----

{{Header
|PrimaryColor = #C90000
|HeaderContent = OOC Note
|SubContent = Only [[Doctor|Doctors]], [[Researcher|Researchers]], [[Nurse|Nurses]] and the [[Chief Medical Officer|CMO]] should be messing with chemical substances. [[Hospital Corpsman|Hospital Corpsmen]] should be aware of overdose thresholds and medications that cause harm when mixed in a patient.
}}

=Tools of the Trade=
# '''Chem''' '''Dispenser''': If you were a marine, this would be your rifle. It dispenses the basic chemicals if a beaker is placed inside. Runs off battery charge which replenishes over time. Has several settings for dispensing chems (5 to 40 units). [[File:ChemLab.png|thumbnail|border|right|Chemistry Lab]]
# '''ChemMaster''': This machine is used to precisely control the amount of chemicals in a beaker, creating bottles and pills. Once a beaker is placed in, you can move desired amounts of it's contents to "buffer" by clicking on buttons present next to the name of the chemical. Clicking again while they're in "buffer" will flush them down disposals, aka they're lost forever. This setting can be changed by the button located between the beaker and buffer contents, just click it once to change to "transfer to beaker." A pill bottle can be inserted into the machine to automatically hold created pills. You can insert and empty beaker into the chem master and click "create bottle" several times to get a bunch of 60u containers for free. You can make Phoron pills and dissolve them in your Phoron beaker as the quickest way of removing it from advanced chems.
# '''Chemical Storage''': Chemical storage. It can hold beakers, bottles, pill bottles, pills, etc etc. Useful for not having your chems all over the floor, but people usually forget to check it when in need of something.
# '''Vendor''': Holds restockable vials of key reagents, and syringes for faster chemical synthesizing.
# '''Beakers''': Several empty beakers that can be used for various purposes, such as storing mixes for the cryo-cells.
# '''Grinder'''/'''Juicer''': This is used to extract chemicals out of many things. For your uses, it'll be mostly pills and food. Most commonly used for grinding solid Phoron for your Clonexadone and Peridaxon needs.
# '''Boxes of pill bottles''': Empty pill bottles to hold up to 16 pills per bottle.
# '''Dropper and 2 beakers of Cryoxadone'''

----

==Equipment==

{| class="wikitable"
|-
! Equipment !! Description
|-
| '''Beakers and Bottles''' ||
* Most basic tool of your trade. Right-clicking one can change it's transfer amount per click. Pills can be dissolved in beakers that already contain something. If you "use" one while holding it in hand, you will put a lid on it, preventing you from splashing it's contents by clicking on the floor by mistake.
* They come in bottle/small beaker - 60u, large beaker - 120u, and bluespace beaker - 300u.
|-
| '''Dropper''' ||
* Like beakers, can be right-clicked for transfer amount. Used for moving small amounts of chemicals between other containers.
|-
| '''Syringe''' ||
* Has two modes switched by "using" it - draw and inject. Hold 15u max, draw 5u per click. Can be used to take blood samples and inject them into mass spectometers for analysis. Using it on harm intent will instantly inject a random amount of the chemical inside while dealing minor brute damage and destroying the syringe. Injecting someone else takes a short time of both standing motionless.
|-
| '''Injector''' ||
* Default ones hold 15u max. Injectors with bigger capacity can be made at the medilathe in research. They can be filled at the centrifuge in research. Pre-loaded injectors cannot be filled with more than their initial amount, for example, a dexalin plus autoinjector can hold only 1u no matter how hard you try to refill it.
|-
| '''Pill''' ||
* 60u max. Takes some time to use on someone, like the syringe. There's also a tiny delay between swallowing a pill and its contents entering your bloodstream, but it's too little to matter. Can be dissolved in a beaker already containing a solution.
|-
| '''Pill Bottle''' ||
* Holds 16 pills max. Clicking on a tile with pills on it while holding the bottle will pick up all the pills scattered on it.
|-
| '''Hypospray''' ||
* Holds 30 units, and comes pre-loaded with tricordrazine. Can be drained and refilled with a syringe or unloaded and loaded with vial. Instantly injects 5u doses.
|-
| '''Syringe Case''' ||
* Holds three syringes/bottles/injectors.
|-
| '''Labellers and Pens'''
||
*Labels can be put on most things you can click on. Only one label may be applied to an item. Activate the labeller without entering a label to remove them.
*Pens replace the name of a chem-master bottle, so instead of bottle (Peridaxon) you get a Peridaxon bottle.
|}

----

=Chemical mixes=
Various common mixes of medical reagents are ordered by hospital corpsmen. '''All of these recipes assume that you are using a bluespace beaker.'''

{| class="wikitable"
|-
! Mix Name !! Vendor and Chem Dispenser !! Chem Dispenser
|-
| {{anchor|imialky}}[[#imialky|'''ImiAlky''' (10u, 5u)]]
Also known as '''IA'''. Results in 160u of Imidazoline and 80u of Alkysine.
Overdoses 30u for both reagents (3 pills).
Used for healing brain damage and eye damage.
||
*Add '''120u''' of Dylovene from the Chem Dispenser.
*Add '''40u''' Chlorine,
*Add '''40u''' Nitrogen,
*Add '''80u''' Carbon,
*Add '''80u''' Hydrogen

Split into 16 pills.<br>

Restock the used bottles back on the Vendor once you are done. This can be done by dragging the bottles in one hand onto the Vendor.
||
*Add '''40u''' Silicon, '''40u''' Nitrogen, '''40u''' Potassium to make '''120u''' of Dylovene,
*Add '''40u''' Chlorine,
*Add '''40u''' Nitrogen,
*Add '''80u''' Carbon,
*Add '''80u''' Hydrogen

Split into 16 pills.<br>
|-
| {{anchor|merabica}}[[#merabica|'''MeraBica''' (7.5u, 7.5u)]]
Also known as '''MB'''. Results in 120u of [[#Meralyne|Meralyne]] and 120u of [[Chemistry#bicaridine|Bicaridine]].<br>

Overdoses on 15u of [[#Meralyne|Meralyne]] and 30u of [[Chemistry#bicaridine|Bicaridine]] (2 and 3 pills respectively).

Rapidly heals Brute damage.
||
*Add '''160u''' Bicaridine,
*Add '''40u''' Water,
*Add '''40u''' Carbon

Split into 16 pills.<br><br>

Restock the used bottles back on the Vendor once you are done. This can be done by dragging the bottles in one hand onto the Vendor.
||
*Add '''160u''' Carbon,
*Add '''40u''' Water,
*Add '''30u''' Oxygen,
*Add '''30u''' Sugar

Remove '''20u''' Bicaridine using the ChemMaster to have '''120u''' of Bicaridine and '''120u''' Meralyne.

Split into 16 pills <br>
|-
| {{anchor|keloderm}}[[#keloderm|'''KeloDerm''' (7.5u, 7.5u)]]
Also known as '''KD'''. Results in 120u of [[Chemistry#kelotane|Kelotane]] and 120u of [[Chemistry#dermaline|Dermaline]].<br>

Overdoses on 30u of [[Chemistry#kelotane|Kelotane]] and 15u of [[Chemistry#dermaline|Dermaline]] (2 pills).

Rapidly heals burn damage.
||
*Add '''160u''' Kelotane,
*Add '''40u''' Oxygen,
*Add '''40u''' Phosphorus

Split into 16 pills.<br><br>

Restock the used bottles back on the Vendor once you are done. This can be done by dragging the bottles in one hand onto the Vendor.
||
*Add '''40u''' Carbon, Carbon, Silicon, Silicon, Oxygen, and Phosphorus.

Split into 16 pills.<br>
|-
| {{anchor|tribica}}[[#tribica|'''TriBica''' (15u, 15u)]]
Also known as '''TB'''. Results in 240u of [[Chemistry#bicaridine|Bicaridine]] and 240u of [[Chemistry#tricordrazine|Tricordrazine]]. <br>

Overdoses at 30u for both reagents (2 pills).

Heals brute damage at a moderate rate and also slowly heals burns and toxin damage.
||
* Add '''60u''' of Inaprovaline,
* Add '''120u''' Bicaridine,
* Add '''60u''' of Dylovene

Split into 8 pills.<br>

* Add '''60u''' of Inaprovaline,
* Add '''120u''' Bicaridine,
* Add '''60u''' of Dylovene

Split into 8 pills.<br>

Restock the used bottles back on the Vendor once you are done. This can be done by dragging the bottles in one hand onto the Vendor.
||
*Add '''40u''' Carbon, Sugar, Oxygen,
*Add '''30u''' Carbon, Carbon,
*Add '''20u''' Nitrogen, Potassium, Silicon

Split into 8 pills.<br>

*Add '''40u''' Carbon, Sugar, Oxygen,
*Add '''30u''' Carbon, Carbon,
*Add '''20u''' Nitrogen, Potassium, Silicon

Split into 8 pills.<br>
|-
| {{anchor|nitrogenwater}}[[#nitrogenwater|'''NitrogenWater''' (10u, 10u)]]
More commonly referred to as '''NW'''. Helps deal with [[Chemistry#tramadol|Tramadol]] overdoses by reacting with in the body to create [[Chemistry#paracetamol|Paracetamol]], which has a higher overdose threshold of '''60u''' compared to [[Chemistry#tramadol|Tramadol's]] '''30u'''.
<br>
Tramadol overdose '''neutralizer'''. Does '''not''' fix toxin damage caused by the overdose.
<br>
This medical reagent has '''no overdose threshold'''. It should however be noted that [[Chemistry#tramadol|Tramadol]] and [[Chemistry#paracetamol|Paracetamol]] are toxic when mixed together. It is advised to double-check the patient for high levels of tramadol before using '''NW'''.
<br>
|| N/A
||
*Add '''40u''' of Nitrogen,
*Add '''40u''' of Water

Split into 4. <br>
|-
| {{anchor|fe}}[[#fe|'''Iron''' (15u)]]
Also known as it's chemical name of '''Fe'''. Adding [[Chemistry#sugar|Sugar]] to the mixture does not help restore more blood. [[Chemistry#sugar|Sugar]] is nutritious to an extent (NTR 1) but not Hemogenic. Results in 240u of [[Chemistry#iron|Iron]]. <br>

Overdoses at '''30u'''. <br>

Hemogenic level 3 (HMG 3). Restores lost blood faster.
||
N/A
||
*Add '''240u''' of [[Chemistry#iron|Iron]]

Split into 16 pills. <br>
|-
|
{{anchor|ironsugar}}[[#ironsugar|'''IronSugar (7.5u, 7.5u)''']]
<br>
Also known as '''IS'''. An objectively less effective version of just Iron. Results in '''120u''' of Sugar and '''120u''' of Iron.

Overdoses at '''30u''' due to the Iron being present in the reagent. <br>
<br>
||
N/A
||
*Add '''120u''' of Iron,
*Add '''120u''' of Sugar

Split to 16. <br>
|-
| {{anchor|atd}}[[#atd|'''AriTricaDylo''' (5u, 5u, 5u)]]
Also known as '''ATD'''. Results in '''80u''' of [[Chemistry#arithrazine|Arithrazine]], '''80u''' of [[Chemistry#dylovene|Dylovene]], and '''80u''' of [[Chemistry#tricordrazine|Tricordrazine]]. <br>

Overdoses at '''15u''' of [[Chemistry#arithrazine|Arithrazine]], '''30u''' of both [[Chemistry#dylovene|Dylovene]] and [[Chemistry#tricordrazine|Tricordrazine]]. (3 and 4 pills respectively).

Potent Toxin damage healer.
||
*Add '''40u''' Inaprovaline,
*Add '''40u''' Phosphorous,
*Add '''180u''' Dylovene.

Remove '''20u''' of [[Chemistry#dylovene|Dylovene]] to make '''80u''' of [[Chemistry#arithrazine|Arithrazine]], '''80u''' of [[Chemistry#dylovene|Dylovene]], and '''80u''' of [[Chemistry#tricordrazine|Tricordrazine]]
Split into 16 pills. <br>
||
*Add '''15u''' Carbon, '''15u''' Oxygen, '''20u''' Sugar to make '''45u''' of Inaprovaline,
*Add '''55u''' Silicon, '''55u''' Nitrogen, '''55u''' Potassium to make '''165u''' of Dylovene,
*Add '''40u''' Phosphorous.
'''NOTE: Very important you do these in the exact order.

Remove '''5u''' Sugar using the ChemMaster to have 80u of [[Chemistry#arithrazine|Arithrazine]], 80u of [[Chemistry#dylovene|Dylovene]], and 80u of [[Chemistry#tricordrazine|Tricordrazine]].

Split into 16 pills.<br>
|-
| {{anchor|dexplus}}[[#dexplus|'''Dexalin Plus''' (7.5u)]]
Also known as '''Dex+'''. Results in '''120u''' of [[Chemistry#dexalinplus|Dexalin Plus]].
<br>
Overdoses on 15u of [[Chemistry#dexalinplus|Dexalin Plus]].
<br>
Dexalin Plus instantly removes any initial oxygen damage.<br>
||
*Add '''40u''' Dexalin,
*Add '''40u''' Carbon,
*Add '''40u''' Iron

Split into 16 pills.
||
*Add '''23u''' of Phoron (grind a bar up and use a dropper)
*Add '''40u''' Oxygen, Oxygen,
*Add '''40u''' Carbon, Iron

To fill up a bottle of Dex+, split ONLY the 120u of Dex+ into 16 pills.<br>
*Add '''40u''' Oxygen, Oxygen,
*Add '''40u''' Carbon, Iron

Repeat the above step 3 more times.

|-
|}

{| class="wikitable"
|-
! Description !! Bottle !! Tank + Bottle
|-
| '''UNGA'''

UNGA is a mix of commonly used medicines combined into one substance: "UNGA juice". The final product should be pink once everything is mixed in. '''UNGA should only be bottled (60u), do not make UNGA pills.'''
||
OD limits depend on the chemicals in contained in the UNGA juice. The OD limit for this version of UNGA will be '''15u''' due to containing Dermaline. It is recommended to add all the medicines in the Bluespace beaker first, then remove certain amounts in the ChemMaster so that every chemical is 12u. This is used to make a full bottle (60u) containing equal proportions.

*Add '''12u''' Tricordrazine,
*Add '''12u''' Bicaridine,
*Add '''12u''' Kelotane,
*Add '''12u''' Dermaline,
*Add '''12u''' Oxycodone,
*Add '''12u''' Meralyne
||Add the following to the tank:
*Add '''120u''' Bicaridine ,
*Add 120u Kelotane,
*Add 60u Inaprovaline,
*Add '''60u''' Dylovene,
*Add '''120u''' Oxycodone
Add the following to a beaker:

* Add 40u Bicaridine,
* Add 40u Kelotane,
* Add 40u Carbon, Water,
* Add 40u Oxygen, Phosphorus

Add the beaker's contents to the tank.
|-
|}

=Chemicals=
The amount of a certain chemical in a marine's blood decreases by its '''metabolism''' value every life tick. Life ticks happen once every 2 seconds. The "effect" column contains the chemical's effects per tick unless stated otherwise.
The ratio column indicates how much of the chem you get when mixing. For example, a chem with a ratio of 4:4 takes 4 units of its component chemicals to make 4 units of the chemical itself.
Chems marked with '''(CATALYST)''' are not expended during the reaction.
The "OD" column for some chemicals has two numbers. The first is the threshold for the "normal" OD, the second is for critical OD. The next column "OD effects" contains the consequences of overdosing on this reagent. '''(C)''' indicates the effect of a critical overdose.

Cocktails and drinks can be found [[Drinks|here]].

==Basic==
Most of these chemicals have little use outside of making more complex ones and can be acquired while on the Almayer from chemical dispensers or via other means.
{| class="wikitable unsortable" style="width: 100%;"
! style="width: 10%; margin: auto;" |Name
! style="width: 20%; margin: auto;" |Effect
! style="width: 12%; margin: auto;" |Properties
! style="margin: auto;" |Acquiring
! style="width: 5%; margin: auto;" |Ratio
! style="width: 5%; margin: auto;" |Meta- bolism
! style="width: 5%; margin: auto;" |OD
! style="width: 20%; margin: auto;" |OD effects
|-
|{{anchor|water}}[[#water|Water]]
|
* Gets things wet.
* Extinguishes fires.
* Explodes when mixed with [[#potassium|potassium]].
|N/A
|
{{:Chemical/Water}}
|3:1
|0,01
|N/A
|N/A

|-
|{{anchor|ethanol}}[[#ethanol|Ethanol]]
|
* Basic alcohol type. [[Drinks#Alcoholic|All other ones]] are a subtype of this.
* Gets you drunk.
* Can be used to remove ink from paper.
|
* [[Researcher#ALH|ALH]] 4
* [[Researcher#FUL|FUL]] 3
* [[Researcher#OXI|OXI]] 3
* [[Researcher#FLW|FLW]] 2
|
{{:Chemical/Ethanol}}
|N/A
|0,2
|N/A
|N/A
|-
|{{anchor|oxygen}}[[#oxygen|Oxygen]]
|
* Fire.
|N/A
|
{{:Chemical/Oxygen}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|copper}}[[#copper|Copper]]
|
* Green fire coloring
|N/A
|
{{:Chemical/Copper}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|nitrogen}}[[#nitrogen|Nitrogen]]
|N/A
|N/A
|
{{:Chemical/Nitrogen}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|hydrogen}}[[#hydrogen|Hydrogen]]
|
* Explosives
|N/A
|
{{:Chemical/Hydrogen}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|potassium}}[[#potassium|Potassium]]
|
* Explodes when mixed with water.
|N/A
|
{{:Chemical/Potassium}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|mercury}}[[#mercury|Mercury]]
|
* Deals 4 brain damage per tick
|
* [[Researcher#NRT|NRT]] 4
|
{{:Chemical/Mercury}}
|N/A
|0,2
|30
|
* Deals 10 brain damage per tick
* Makes you jittery
* Makes you drowsy
|-
|{{anchor|sulfur}}[[#sulfur|Sulfur]]
|N/A
|N/A
|
{{:Chemical/Sulphur}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|carbon}}[[#carbon|Carbon]]
|
* Chemfire modifier
|N/A
|
{{:Chemical/Carbon}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|chlorine}}[[#chlorine|Chlorine]]
|
* Deals 0.5 brute damage per tick
|
* [[Researcher#BCD|BCD]] 1
|
{{:Chemical/Chlorine}}
|N/A
|0,2
|
* 30
* 50
|
* Deals 1.5 brute damage per tick
* '''(C)''' Deals 4 brute damage per tick
|-
|{{anchor|fluorine}}[[#fluorine|Fluorine]]
|
* Deals 0.5 toxin damage per tick
|
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Flourine}}
|N/A
|0,2
|
* 30
* 50
|
* Deals 1.5 toxin damage per tick
* '''(C)''' Deals 4 toxin damage per tick
|-
|{{anchor|sodium}}[[#sodium|Sodium]]
|N/A
|N/A
|
{{:Chemical/Sodium}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|phosphorus}}[[#phosphorus|Phosphorus]]
|
* Fire modifier
|N/A
|
{{:Chemical/Phosphorus}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|lithium}}[[#lithium|Lithium]]
|
* Fire modifier
* Makes you less confused and sends messages in chat.
|
* [[Researcher#OXI|OXI]] 1
* [[Researcher#PST|PST]] 1
|
{{:Chemical/Lithium}}
|N/A
|0,2
|
* 30
* 50
|
* Deals 0.5 brain damage per tick
* '''(C)''' Deals 3 brain damage per tick
* '''(C)''' Makes you hallucinate
|-
|{{anchor|nutriment}}[[#nutriment|Nutriment]]
|
* Nutritious. Helps restore lost blood.
|
* [[#NTR|NTR]] 1
|
{{:Chemical/Nutriment}}
|N/A
|0,2
|N/A
|N/A
|-
|-
|{{anchor|sugar}}[[#sugar|Sugar]]
|
* Nutritious. Helps restore lost blood.
|
* [[#NTR|NTR]] 1
|
{{:Chemical/Sugar}}
|N/A
|0,2
|N/A
|N/A
|-
|{{anchor|iron}}[[#iron|Iron]]
|
* Turns nutrition into blood.
|
* [[Researcher#HMG|HMG]] 3
|
{{:Chemical/Iron}}
|N/A
|0,2
|
* 30
* 50
|
* Deals 1.5 toxin damage per tick
* '''(C)''' Makes you really hungry
|-
|{{anchor|gold}}[[#gold|Gold]]
|N/A
|N/A
|
{{:Chemical/Gold}}
|N/A
|0,2
|N/A
|N/A
|-
|{{anchor|silver}}[[#silver|Silver]]
|N/A
|N/A
|
{{:Chemical/Silver}}
|N/A
|0,2
|N/A
|N/A
|-
|{{anchor|uranium}}[[#uranium|Uranium]]
|
* Deals 0.5 radiation damage per tick
|
* [[Researcher#CRG|CRG]] 2
|
{{:Chemical/Uranium}}
|N/A
|0,2
|N/A
|N/A
|-
|{{anchor|aluminium}}[[#aluminium|Aluminium]]
|N/A
|N/A
|
{{:Chemical/Aluminium}}
|N/A
|0,2
|N/A
|N/A
|-
|{{anchor|silicon}}[[#silicon|Silicon]]
|N/A
|N/A
|
{{:Chemical/Silicon}}
|N/A
|0,2
|N/A
|N/A
|-
|{{anchor|weldingfuel}}[[#weldingfuel|Welding Fuel]]
|
* Fire modifier
* Deals 0.5 toxin damage per tick
|
* [[Researcher#FUL|FUL]] 5
* [[Researcher#OXI|OXI]] 3
* [[Researcher#VIS|VIS]] 4
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Welding Fuel}}
|N/A
|0,2
|
* 30
* 50
|
* Deals 1.5 toxin damage per tick
* '''(C)''' Deals 4 toxin damage per tick
|-
|{{anchor|phoron}}[[#phoron|Phoron]]
|
* Fire modifier
* Deals 0.5 toxin damage per tick
|
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Phoron}}
|N/A
|0,1
|N/A
|N/A
|-
|{{anchor|radium}}[[#radium|Radium]]
|
* Deals 0.5 radiation damage per tick
|
* [[Researcher#CRG|CRG]] 2
|
{{:Chemical/Radium}}
|N/A
|0,2
|N/A
|N/A
|}

==Medical==
These chemicals are used for healing damage and generally keeping marines healthy. Some reagents that technically don't have a tangible gameplay effect but are in the medical chem code are included. (Mainly various antidepressants)
{| class="wikitable sortable" style="width: 100%;"
! style="width: 1%; margin: auto;" |Name
! style="width: 20%; margin: auto;" scope=col class=unsortable |Effect
! style="width: 12%; margin: auto;" scope=col class=unsortable |Properties
! style="margin: auto;" scope=col class=unsortable |Recipe
! style="width: 1%; margin: auto;" scope=col class=unsortable |Ratio
! style="width: 5%; margin: auto;" scope=col class=unsortable |Meta- bolism
! style="width: 1%; margin: auto;" scope=col class=unsortable |OD
! style="width: 20%; margin: auto;" scope=col class=unsortable |OD effects
|-
|{{anchor|inaprovaline}}[[#inaprovaline|Inaprovaline]]
|
* Prevents gaining further oxygen damage from being in crit.
|
* [[Researcher#CSL|CSL]] 3
|
* Weylandmeds.
{{:Chemical/Inaprovaline}}
|3:3
|0,2
|
* 60
* 100
|
* Knocks you out.
* Causes Jitter
* '''(C)''' Deals 0,5 heart damage per tick.
* '''(C)''' Sleeps you.
|-
|{{anchor|paracetamol}}[[#paracetamol|Paracetamol]]
|
* Reduces pain.
|
* [[Researcher#PNK|PNK]] 2
|
{{:Chemical/Paracetamol}}
|3:3
|0,05
|
* 60
* 100
|
* Makes you hallucinate.
* Deals 2 toxin damage per tick.
* '''(C)''' Deals 3 liver damage per tick.
* '''(C)''' Deals 1 brain damage per tick.
* '''(C)''' Deals 3 oxygen damage per tick.
|-
|{{anchor|ryetalyn}}[[#ryetalyn|Ryetalyn]]
|
* Fixes disabilities and disfigurements.
|
* [[Researcher#AID|AID]] 2
|
{{:Chemical/Ryetalyn}}
|2:2
|0,2
|
* 30
* 50
|
* Makes you confused.
* Deals 1 toxin damage per tick.
* '''(C)''' Knocks you out.
* '''(C)''' Deals 2 toxin damage per tick.
* '''(C)''' Deals 3 radiation damage per tick.
|-
|{{anchor|tramadol}}[[#tramadol|Tramadol]]
|
* Reduces pain.
|
* [[Researcher#PNK|PNK]] 5
|
* Weylandmeds.
{{:Chemical/Tramadol}}
|3:3
|0,05
|
* 30
* 50
|
* Makes you hallucinate.
* Deals 2.5 toxin damage per tick.
* '''(C)''' Deals 7.5 liver damage per tick.
* '''(C)''' Deals 2.5 brain damage per tick.
* '''(C)''' Deals 3 oxygen damage per tick.
|-
|{{anchor|oxycodone}}[[#oxycodone|Oxycodone]]
|
* Reduces pain.
|
* [[Researcher#PNK|PNK]] 8
|
* Weylandmeds.
{{:Chemical/Oxycodone}}
|2:1
|0,1
|
* 20
* 30
|
* Makes you hallucinate.
* Deals 4 toxin damage per tick.
* '''(C)''' Deals 12 liver damage per tick.
* '''(C)''' Deals 4 brain damage per tick.
* '''(C)''' Deals 3 oxygen damage.
|-
|{{anchor|leporazine}}[[#leporazine|Leporazine]]
|
* Attempts to stabilize your temperature.
|
* [[Researcher#TSL|TSL]] 2
|
{{:Chemical/Leporazine}}
|2:2
|0,2
|
* 30
* 50
|
* Knocks you out.
* '''(C)''' Sleeps you.
|-
|{{anchor|kelotane}}[[#kelotane|Kelotane]]
|
* Heals 1 burn damage per tick.
|
* [[Researcher#ACR|ACR]] 2
|
* Weylandmeds.
{{:Chemical/Kelotane}}
|2:2
|0,2
|
* 30
* 50
|
* Deals 1 brute and toxin damage per tick.
* '''(C)''' Deals 5.5 brute and toxin damage per tick.
|-
|{{anchor|dermaline}}[[#dermaline|Dermaline]]
|
* Heals 1.5 burn damage per tick.
|
* [[Researcher#ACR|ACR]] 3
|
{{:Chemical/Dermaline}}
|3:3
|0,2
|
* 15
* 25
|
* Deals 1.5 brute and toxin damage per tick.
* '''(C)''' Deals 9 brute and toxin damage per tick.
|-
|{{anchor|Meralyne}}[[#Meralyne|Meralyne]]
|
* Heals 1.5 brute damage per tick.
|
* [[Researcher#NGN|NGN]] 3
|
{{:Chemical/Meralyne}}
|3:3
|0,2
|
* 15
* 25
|
* Deals 1.5 burn damage per tick.
* '''(C)''' Deals 9 burn and 3 toxin damage per tick.
|-
|{{anchor|dexalin}}[[#dexalin|Dexalin]]
|
* Repairs 4 oxygen damage. 
* Removes 4u of [[#lexorin|lexorin]] per tick.
|
* [[Researcher#OXG|OXG]] 4
|
* Weylandmeds.
* Recipe:
{{:Chemical/Dexalin}}
|2,1:1
|0,2
|
* 30
* 50
|
* Deals 2 toxin damage per tick.
* '''(C)''' Deals 4 brute damage per tick.
* '''(C)''' Deals 8 toxin damage per tick.
|-
|{{anchor|dexalinplus}}[[#dexalinplus|Dexalin Plus]]
|
* Repairs all oxygen damage instantly.
* Removes 6u of [[#lexorin|lexorin]] per tick.
|
* [[Researcher#OXG|OXG]] 6
|
{{:Chemical/Dexalin Plus}}
|3:3
|0,2
|
* 15
* 25
|
* Deals 1.5 toxin damage per tick.
* '''(C)''' Deals 3 brute damage per tick.
* '''(C)''' Deals 7.5 toxin damage per tick.
|-
|{{anchor|tricordrazine}}[[#tricordrazine|Tricordrazine]]
|
* Heals 0.5 brute damage.
* Heals 0.5 burn damage.
* Heals 0.5 toxin damage.
* Heals 0.5 oxygen damage.
* Removes 1u of  all types of [[#toxin|toxin]].
|
* [[Researcher#NGN|NGN]] 1
* [[Researcher#ACR|ACR]] 1
* [[Researcher#ATX|ATX]] 1
* [[Researcher#OXG|OXG]] 1
|
{{:Chemical/Tricordrazine}}
|2:2
|0,2
|
* 30
* 50
|
* Deals 0.5 burn damage
* Deals 0.5 brute damage.
* Deals 0.25 toxin damage.
* Deals 0.5 Eye damage.
* '''(C)''' Deals 2.5 burn damage.
* '''(C)''' Deals 4 toxin damage.
* '''(C)''' Deals 2.5 brute damage.
* "(C)" Sleeps you
|-
|{{anchor|dylovene}}[[#dylovene|Dylovene]]
|
* Heals 2 toxin damage.
* Removes 1u of [[#toxin|toxin]] of any type.
* Removes 5u of [[#mindbreaker|mindbreaker toxin]].
* Removes 5u of [[#spacedrugs|space drugs]]
* Reduces the potency of hallucinations and other drug-related effects.
|
* [[Researcher#ATX|ATX]] 2
* [[Researcher#AHL|AHL]] 2
|
* Weylandmeds.
{{:Chemical/Dylovene}}
|3:3
|0,2
|
* 30
* 50
|
* Deals 1 eye damage..
* '''(C)''' Sleeps you.
* '''(C)''' Deals 1 burn damage.
* '''(C)''' Deals 1 brute damage.
* '''(C)''' Deals 2 toxin damage.

|-
|{{anchor|thwei}}[[#thwei|Thwei]]
|
* Heals 1,2 brute damage.
* Heals 1 toxin damage.
* Heals 1 organ damage.
* Removes 1u of [[#toxin|toxin]] of any type.
* Heals all oxygen damage.
* Removes 6u of [[#lexorin|lexorin]].
* Heals 6 radiation damage per tick.
* Repairs bones (splinted/unsplinted in minutes)
** Chest and groin: 3 / 7
** Head: 1 / 5
** Hands and feet: 0,5 / 0,5
** Arms and legs: 0,5 / 1
* Rapidly restores lost blood.
** '''(HUMAN ONLY)''' After blood is over maximum starts deals 9 brute, 9 burn, and 18 oxygen damage per tick.
* Fixes disabilities and disfigurements.
* Removes 5u of [[#mindbreaker|mindbreaker]].
* Removes 5u of [[#spacedrugs|space drugs]].
* Weakens drug-related effects.
* Removes 6u of [[#ethanol|ethanol]] and [[Drinks|other alcohol]].
* Fixes confusion, stuttering, temporary blindness, dizziness, jitteriness, and wakes you up.
* Fixes eye damage.
* Cures the zombie virus (black goo).
* Cures a certain other rare disease. 
|
* [[Researcher#XMB|XMB]] 1
* [[Researcher#ATX|ATX]] 1
* [[Researcher#HMG|HMG]] 9
* [[Researcher#OXG|OXG]] 6
* [[Researcher#ACG|ACG]] 6
* [[Researcher#BNM|BNM]] 6
* [[Researcher#AID|AID]] 1
* [[Researcher#AHL|AHL]] 2
* [[Researcher#FCS|FCS]] 6
* [[Researcher#CUR|CUR]] 4
|
{{:Chemical/Thwei}}
|N/A
|0,2
|N/A
|N/A
|-

|-
|{{anchor|neuraline}}[[#neuraline|Neuraline]]
|
* Weakens stuns and knockdowns.
* Fixes stuttering, blurry vision, confusion, dizziness, jitteriness and drowsiness.
|
* [[Researcher#NST|NST]] 5
|
{{:Chemical/Neuraline}}
|N/A
|0,4
|
* 2
* 3
|
* Deals 10 toxin damage.
* '''(C)''' Deals 5 brute damage.
* '''(C)''' Deals 5 burn damage.
* '''(C)''' Deals 15 toxin damage.
|-
|{{anchor|arithrazine}}[[#arithrazine|Arithrazine]]
|
* Heals 1 toxin damage.
* Removes 1u of any type of [[#toxin|toxin]].
* Deals 1 brute damage.
|
* [[Researcher#ATX|ATX]] 1
* [[Researcher#BCD|BCD]] 1
|
{{:Chemical/Arithrazine}}
|2:2
|0,05
|
* 15
* 25
|
* Deals 1 eye damage.
* Deals 2 brute damage.
* '''(C)''' Sleeps you.
* '''(C)''' Deals 4 brute damage.
|-
|{{anchor|russianred}}[[#russianred|Russian Red]]
|
* Heals 1 toxin damage.
* Removes 1u of any type of [[#toxin|toxin]].
* Deals 2 brute damage.
|
* [[Researcher#ATX|ATX]] 1
* [[Researcher#BCD|BCD]] 2
|
{{:Chemical/Russian Red}}
|N/A
|1
|
* 20
* 30
|
* Deals 1 eye damage.
* Deals 4 brute damage.
* '''(C)''' Sleeps you.
* '''(C)''' Deals 8 brute damage.
|-
|{{anchor|alkysine}}[[#alkysine|Alkysine]]
|
* Heals 3 brain damage per tick.
|
* [[Researcher#NRP|NRP]] 2
|
{{:Chemical/Alkysine}}
|3:2
|0,05
|
* 30
* 50
|
* Deals 1 toxin damage.
* '''(C)''' Deals 3 brain damage.
* '''(C)''' Stuns you.
|-
|{{anchor|imidazoline}}[[#imidazoline|Imidazoline]]
|
* Heals 1 eye damage.
* Fixes blurry vision and blindness.
|
* [[Researcher#OCP|OCP]] 2
|
{{:Chemical/Imidazoline}}
|3:2
|0,2
|
* 30
* 50
|
* Deals 1 toxin damage.
* '''(C)''' Deals 1 brute damage.
* '''(C)''' Deals 1 burn damage.
* '''(C)''' Deals 4 toxin damage.
* '''(C)''' Deals 1 brain damage.
|-
|{{anchor|peridaxon}}[[#peridaxon|Peridaxon]]
|
* Prevents you from suffering consequences of organ damage.
* Does '''NOT''' fix organs.
|
* [[Researcher#OGS|OGS]] 4
|
* Weylandmeds.
* Recipe:
{{:Chemical/Peridaxon}}
|4:2
|0,05
|
* 15
* 25
|
* Deals 2 brute damage.
* '''(C)''' Deals 8 brute damage.
* '''(C)''' Deals 6 burn damage.
* '''(C)''' Deals 6 toxin damage.
|-
|{{anchor|bicaridine}}[[#bicaridine|Bicaridine]]
|
* Heals 1 brute damage per tick.
|
* [[Researcher#NGN|NGN]] 2
|
* Weylandmeds.
* Recipe:
{{:Chemical/Bicaridine}}
|2:2
|0,2
|
* 30
* 50
|
* Deals 1 burn damage.
* '''(C)''' Deals 6 burn damage
* '''(C)''' Deals 2 toxin damage.
|-
|{{anchor|epinephrine}}[[#epinephrine|Epinephrine]]
|
* '''MUST BE INJECTED. CANNOT TAKE IN PILLS.'''
* Increases defibrillator healing by 16 per damage type.
* Reduces pain.
* Makes you move faster.
* A small amount is consumed on each defib attempt.
|
* [[Researcher#PNK|PNK]] 1,5 
* [[Researcher#EGN|EGN]] 4
* [[Researcher#INV|INV]] 1
|
{{:Chemical/Epinephrine}}
|3:2
|0,4
|
* 10,5
* 20
|
* '''(C)''' Deals 1 brute damage.
|-
|{{anchor|ultrazine}}[[#ultrazine|Ultrazine]]
|
* Makes you much faster.
* Makes you addicted to it.
|
* [[Researcher#MST|MST]] 40
* [[Researcher#ADT|ADT]] 8
|
{{:Chemical/Ultrazine}}
|N/A
|0,0167 
|
* 10,5
* 20
|
* Deals 40 heart damage.
* Deals 8 brain damage.
* '''(C)''' Deals 40 brute damage.
* '''(C)''' Makes you nervous. 

|-
|{{anchor|cryoxadone}}[[#cryoxadone|Cryoxadone]]
|
* ''' ONLY FUNCTIONS AT LOW TEMPERATURES. USE A CRYO TUBE.''' 
* Heals 3 radiation damage.
* Heals 3 brute damage.
* Heals 3 burn damage.
* Heals 3 toxin damage.
* Heals 1 oxygen damage.
|
* [[Researcher#CMB|CMB]] 2
* [[Researcher#NGN|NGN]] 1
* [[Researcher#ACR|ACR]] 1
* [[Researcher#ATX|ATX]] 1
* [[Researcher#ACG|ACG]] 1
|
{{:Chemical/Cryoxadone}}
|3:3
|0,2
|N/A
|N/A
|-
|{{anchor|clonexadone}}[[#clonexadone|Clonexadone]]
|
* '''AS ABOVE''' 
* Heals 6 radiation damage.
* Heals 6 brute damage.
* Heals 6 burn damage.
* Heals 6 toxin damage.
|
* [[Researcher#CMB|CMB]] 6
* [[Researcher#NGN|NGN]] 3
* [[Researcher#ACR|ACR]] 3
* [[Researcher#ATX|ATX]] 3
* [[Researcher#ACG|ACG]] 3
|
{{:Chemical/Clonexadone}}
|2,1:2
|0,2
|N/A
|N/A
|-
|{{anchor|rezadone}}[[#rezadone|Rezadone]]
|
* Heals 1 brute damage.
* Removes disabilities and disfigurements.
* Heals 2 radiation damage.
* Deals 2 toxin damage.
|
* [[Researcher#NGN|NGN]] 1
* [[Researcher#AID|AID]] 3
* [[Researcher#TOX|TOX]] 2
* [[Researcher#ACG|ACG]] 2
|
{{:Chemical/Rezadone}}
|3:3
|0,2
|
* 30
* 50
|
* Deals 1 burn damage.
* Makes you confused.
* Deals 11 toxin damage.
* '''(C)''' Knocks you out.
* '''(C)''' Deals 13 toxin damage.
* '''(C)''' Deals 9 radiation damage.
* '''(C)''' Deals 4 burn damage.
* '''(C)''' Deals 4 brute damage.
|-
|{{anchor|spaceacillin}}[[#spaceacillin|Spaceacillin]]
|
* Cures mundane infections like the flu.
|
* [[Researcher#UNK|UNK]] 1
|
{{:Chemical/Spaceacillin}}
|2:2
|0,01
|
* 30
* 50
|
* Deals 1 brute damage.
* '''(C)''' Deals 3 brute damage.
* '''(C)''' Deals 3 burn damage.
* '''(C)''' Deals 3 toxin damage.
|-
|{{anchor|ethylredoxrazine}}[[#ethylredoxrazine|Ethylredoxrazine]]
|
* Removes confusion, drowsiness, stuttering, blurry vision, blindness, dizziness, and jitteriness.
* Removes 3u [[#ethanol|ethanol]] and [[Drinks|other alcohols]] from the body.
* Reacts with [[#ethanol|ethanol]] to turn into water.
|
* [[Researcher#FCS|FCS]] 3
|
{{:Chemical/Ethylredoxrazine}}
|3:3
|0,2
|
* 30
* 50
|
* Deals 1.5 toxin damage per tick
* '''(C)''' Deals 6 toxin damage per tick
|-
|{{anchor|methylphenidate}}[[#methylphenidate|Methylphenidate]]
|
* Gives you messages about your mind becoming clearer.
* Removes confusion.
|
* [[Researcher#PST|PST]] 4
|
{{:Chemical/Methylphenidate}}
|2:3
|0,01
|N/A
|N/A
|-
|{{anchor|citalopram}}[[#citalopram|Citalopram]]
|
* As above.
|
* [[Researcher#PST|PST]] 2
|
{{:Chemical/Citalopram}}
|2:3
|0,01
|N/A
|N/A
|-
|{{anchor|paroxetine}}[[#paroxetine|Paroxetine]]
|
* As above.
* Makes you hallucinate.
* Makes you jittery.
|
* [[Researcher#PST|PST]] 6
* [[Researcher#HLG|HLG]] 6
|
{{:Chemical/Paroxetine}}
|3:3
|0,01
|N/A
|N/A
|-
|{{anchor|antized}}[[#antized|Anti-Zed]]
|
* Prevents zombies from reviving.
* Cures the zombie virus.
* Cures all other diseases as well.
|
* [[Researcher#CUR|CUR]] 2
|
{{:Chemical/Anti-Zed}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|sterilizine}}[[#sterilizine|Sterilizine]]
|
* Sterilizes surfaces. Since we don't actually need to do that, this has no use outside of RP.
|N/A
|
{{:Chemical/Sterilizine}}
|3:3
|0,2
|N/A
|N/A
|-
|{{anchor|soporific}}[[#soporific|Soporific]]
|
* Puts you to sleep.
* Reduces pain.
|
* [[Researcher#PNK|PNK]] 10
* [[Researcher#SDT|SDT]] 2
|
{{:Chemical/Soporific}}
|5:5
|0,1
|
* 30
* 50
|
* Makes you hallucinate.
* Deals 5 toxin damage.
* '''(C)''' Deals 15 liver damage.
* '''(C)''' Deals 5 brain damage.
* '''(C)''' Deals 3 oxygen damage.
|-
|{{anchor|vaccine}}[[#vaccine|Vaccine]]
|
* Prevents you from catching the virus this is a vaccine against.
* Cures the zombie virus.
* Prevents dead zombies from reviving.
* Cures all other diseases as well.
|
* [[Researcher#CUR|CUR]] 4
|
{{:Chemical/Vaccine}}
|N/A
|0,2
|N/A
|N/A
|-
|{{anchor|antineurotoxin}}[[#antineurotoxin|Anti-Neurotoxin]]
|
* Note that '''technically''', as far as the code is concerned, this is a subtype of xeno plasmas.
* Protects you from [[Sentinel|getting shot with any kind of neuro]].
|
* [[Researcher#NRS|NRS]] 1
|
{{:Chemical/Anti-Neurotoxin}}
|2:1
|0,4
|
* 30
* 50
|
* Deals 1 liver damage.
* '''(C)''' Deals 2 brain damage.
|-
|{{anchor|lipozine}}[[#lipozine|Lipozine]]
|
* Causes you to lose fat and makes you hungry
|
* [[Researcher#KTG|KTG]] 4
|
{{:Chemical/Lipozine}}
|3:3
|0.05
|
* 30
* 50
|
* Makes you even more hungry
* '''(C)''' Deals 2 toxin Damage
|}

==Toxins and acids==
Most of these chemicals generally don't have much use outside of murder.
{| class="wikitable unsortable" style="width: 100%;"
! style="width: 10%; margin: auto;" |Name
! style="width: 20%; margin: auto;" |Effect
! style="width: 12%; margin: auto;" |Properties
! style="margin: auto;" |Recipe
! style="width: 5%; margin: auto;" |Ratio
! style="width: 5%; margin: auto;" |Meta- bolism
! style="width: 5%; margin: auto;" |OD
! style="width: 20%; margin: auto;" |OD effects
|-
|{{anchor|generictoxin}}[[#generictoxin|Generic Toxin]]
|
* Most other chemicals in this table are a subtype of this one.
* Deals 1 toxin damage every tick.
|
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Generic Toxin}}
|N/A
|0,1
|N/A
|N/A
|-
|{{anchor|toxin}}[[#toxin|Toxin]]
|
* Deals 0.5 toxin damage per tick.
|
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Toxin}}
|2:2
|1
|N/A
|N/A
|-

|-
|{{anchor|mutagen}}[[#mutagen|Unstable Mutagen]]
|
* Deals 0,5 radiation damage per tick.
|
* [[Researcher#CRG|CRG]] 1
|
{{:Chemical/Unstable Mutagen}}
|3:3
|0,1
|N/A
|N/A
|-
|{{anchor|lexorin}}[[#lexorin|Lexorin]]
|
* Deals 8 oxygen damage per tick.
* Deals 0.5 brute damage per tick.
|
* [[Researcher#HPX|HPX]] 8
* [[Researcher#BCD|BCD]] 1
|
{{:Chemical/Lexorin}}
|3:3
|0,1
|
* 30
* 50
|
* Deals 5.5 brute damage.
* Deals 4 toxin damage.
* Deals 28 oxygen damage.
* '''(C)''' Deals 28 brute and oxygen damage.
* '''(C)''' Deals 12 toxin damage.
|-
|{{anchor|cyanide}}[[#cyanide|Cyanide]]
|
* Deals 8 oxygen damage.
* Puts you to sleep after a while.
|
* [[Researcher#HPX|HPX]] 4
* [[Researcher#SDT|SDT]] 1
|
{{:Chemical/Cyanide}}
|N/A
|0,4
|N/A
|N/A
|-
|{{anchor|minttoxin}}[[#minttoxin|Mint Toxin]]
|
* Deals 1 toxin damage.
|
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Mint Toxin}}
|N/A
|0,1
|N/A
|N/A
|-
|{{anchor|carpotoxin}}[[#carpotoxin|Carpotoxin]]
|
* Deals 2 toxin damage.
|
* [[Researcher#TOX|TOX]] 2
|
{{:Chemical/Carpotoxin}}
|N/A
|0,1
|N/A
|N/A

|-
|{{anchor|chloralhydrate}}[[#chloralhydrate|Chloral Hydrate]]
|
* Deals 0.5 toxin damage.
* Puts you to sleep.
|
* [[Researcher#SDT|SDT]] 6
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Chloral Hydrate}}
|
|0,1
|
* 15
* 25
|
* Deals 1.5 toxin damage.
* Knocks you out.
* '''(C)''' Deals 4 toxin damage.
* '''(C)''' Deals 15 oxygen damage.
|-
|{{anchor|potassiumchloride}}[[#potassiumchloride|Potassium Chloride]]
|
* Fire modifier.
* Deals 4 oxygen damage.
* Slows you.
|
* [[Researcher#HPX|HPX]] 2
* [[Researcher#RLX|RLX]] 4
|
{{:Chemical/Potassium Chloride}}
|2:2
|0,2
|30
|
* Deals 2 brute damage.
* Deals 2 toxin damage.
* Deals 10 oxygen damage.
* Slows you down by a lot.
|-
|{{anchor|potassiumchlorophoride}}[[#potassiumchlorophoride|Potassium Chlorophoride]]
|
* Slows you down.
* Deals 8 oxygen damage.
* Deals 2 toxin damage.
|
* [[Researcher#RLX|RLX]] 8
* [[Researcher#HPX|HPX]] 4
* [[Researcher#TOX|TOX]] 2
|
{{:Chemical/Potassium Chlorophoride}}
|3:4
|0,2
|20
|
* Deals 4 brute damage.
* Deals 4 toxin damage.
* Deals 20 oxygen damage.
* Deals 4 toxin damage.
* Slows you down by a lot.

|-
|{{anchor|sulphuricacid}}[[#sulphuricacid|Sulphuric Acid]]
|
* Has a chance to melt items when poured/sprayed on them. Worn headgear included.
* Deals 0.5 toxin damage per tick.
* Deals 1.5 burn damage per tick.
|
* [[Researcher#TOX|TOX]] 1
* [[Researcher#CRS|CRS]] 3
|
{{:Chemical/Sulphuric Acid}}
|7:1
|0,1
|N/A
|N/A
|-
|{{anchor|polytrinicacid}}[[#polytrinicacid|Polytrinic Acid]]
|
* As above, but a higher chance to melt.
* Deals 1 toxin damage per tick.
* Deals 1.5 burn damage per tick.
|
* [[Researcher#CRS|CRS]] 3
* [[Researcher#TOX|TOX]] 2
|
{{:Chemical/Polytrinic Acid}}
|3:3
|0,1
|N/A
|N/A
|-
|{{anchor|formaldehyde}}[[#formaldehyde|Formaldehyde]]
|
* Deals 1 toxin damage.
* Deals 0,5 radiation damage.
* Ingredient for explosives.
|
* [[Researcher#TOX|TOX]] 1
* [[Researcher#CRG|CRG]] 1
|
{{:Chemical/Formaldehyde}}
|3:3
|0,1
|N/A
|N/A
|-
|{{anchor|paraformaldehyde}}[[#paraformaldehyde|Paraformaldehyde]]
|
* Deals 1 toxin damage.
* Ingredient for explosives.
|
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Paraformaldehyde}}
|2:1
|0,1
|N/A
|N/A
|-
|{{anchor|impedrezene}}[[#Impedrezene|Impedrezene]]
|
* Deals 3,5 brain damage.
* Slows you down.
|
* [[Researcher#NRT|NRT]] 2
* [[Researcher#RLX|RLX]] 1
|
{{:Chemical/Impedrezene}}
|3:2
|0,2
|
* 30
* 50
|
* Deals 6 brain damage.
* Makes you sleepier.
* Slows you down by a lot.
* '''(C)''' Has a chance to knock you out.
* '''(C)''' Deals 1 oxygen damage.
* '''(C)''' Deals 0,75 heart damage.
* '''(C)''' Has a chance to knock you down.
|}

==Drugs==
Reagents that get marines high.
{| class="wikitable unsortable" style="width: 100%;"
! style="width: 10%; margin: auto;" |Name
! style="width: 20%; margin: auto;" |Effect
! style="width: 12%; margin: auto;" |Properties
! style="margin: auto;" |Recipe
! style="width: 5%; margin: auto;" |Ratio
! style="width: 5%; margin: auto;" |Meta- bolism
! style="width: 5%; margin: auto;" |OD
! style="width: 20%; margin: auto;" |OD effects
|-
|{{anchor|mindbreaker}}[[#mindbreaker|Mindbreaker Toxin]]
|
* Literally LSD.
* Makes you hallucinate.
* Makes you high.
* Makes you jittery.
|
* [[Researcher#HLG|HLG]] 8
|
{{:Chemical/Mindbreaker Toxin}}
|3:3
|0,1
|
* 30
* 50
|
* Makes you hallucinate more.
* Makes you stumble around.
* '''(C)''' Deals 4 brain damage.
* '''(C)''' Knocks you out.
|-
|{{anchor|spacedrugs}}[[#spacedrugs|Space Drugs]]
|
* Baby's first drug.
* Makes you high.
|
* [[Researcher#HLG|HLG]] 2
|
{{:Chemical/Space Drugs}}
|3:3
|0,2
|
* 30
* 50
|
* Makes you hallucinate.
* Makes you jittery.
* '''(C)''' Deals 2 brain damage.
* '''(C)''' Knocks you out.
|-
|{{anchor|psilocybin}}[[#psilocybin|Psilocybin]]
|
* Makes you high.
* Makes you hallucinate.
* Makes you jittery.
|
* [[Researcher#HLG|HLG]] 3
|
{{:Chemical/Psilocybin}}
|N/A
|0,2
|
* 30
* 50
|
* Makes you hallucinate more.
* Makes you stumble around.
* '''(C)''' Deals 3 brain damage.
* '''(C)''' Knocks you out.
|-
|{{anchor|nicotine}}[[#nicotine|Nicotine]]
|N/A 
|N/A
|
{{:Chemical/Nicotine}}
|N/A
|0,2
|N/A
|N/A
|}

==Xeno blood and plasma==
Chemicals acquired from xenos.
{| class="wikitable unsortable" style="width: 100%;"
! style="width: 10%; margin: auto;" |Name
! style="width: 20%; margin: auto;" |Effect
! style="width: 12%; margin: auto;" |Properties
! style="margin: auto;" |Recipe
! style="width: 5%; margin: auto;" |Ratio
! style="width: 5%; margin: auto;" |Meta- bolism
! style="width: 5%; margin: auto;" |OD
! style="width: 20%; margin: auto;" |OD effects
|-
|{{anchor|xenoblood}}[[#xenoblood|Acidic Blood]]
|
* Deals 3 burn damage.
|
* [[Researcher#CRS|CRS]] 3
|
{{:Chemical/Acidic Blood}}
|N/A
|N/A
|N/A
|N/A
|-
|{{anchor|royalxenoblood}}[[#royalxenoblood|Dark Acidic Blood]]
|
* Deals 6 burn damage.
|
* [[Researcher#CRS|CRS]] 6
|
Queen and Praetorians.
|N/A
|N/A
|N/A
|N/A
|-
|{{anchor|plasma}}[[#plasma|Plasma]]
|
* Base type for all of the following.
|N/A
|{{:Chemical/Plasma}}
|N/A
|0,4
|N/A
|N/A
|-
|{{anchor|pheromoneplasma}}[[#pheromoneplasma|Pheromone Plasma]]
|
* Makes you high.
* Makes you hallucinate.
* Helps you with knockdowns, knockouts and stuns.
* Fixes stuttering, confusion, blurry vision, drowsiness, dizziness, and jitteriness.
|
* [[Researcher#HLG|HLG]] 8
* [[Researcher#NST|NST]] 6
|
{{:Chemical/Pheromone Plasma}}
|N/A
|0,4
|30
|
* Makes you stumble around.
* Makes you hallucinate more.
* Deals 12 toxin damage.
* '''(C)''' Deals 8 brain damage.
* '''(C)''' Knocks you out.
* '''(C)''' Deals 6 brute damage.
* '''(C)''' Deals 6 burn damage.
* '''(C)''' Deals 18 toxin damage.
|-
|{{anchor|chitinplasma}}[[#chitinplasma|Chitin Plasma]]
|
* Prevents fractures.
|
* [[Researcher#HDN|HDN]] 1
|
{{:Chemical/Chitin Plasma}}
|N/A
|0,4
|
* 30
* 50
|
* Slows you down.
* '''(C)''' Deals 3 brute damage.
|-
|{{anchor|catecholamineplasma}}[[#catecholamineplasma|Catecholamine Plasma]]
|
* Applies pain.
* Makes you faster.
|
* [[Researcher#PNG|PNG]] 2
* [[Researcher#MST|MST]] 6
|
{{:Chemical/Catecholamine Plasma}}
|N/A
|0,4
|
* 30
* 50
|
* Increased pain.
* Deals 2 brute damage.
* Deals 6 heart damage.
* '''(C)''' Deals 10 brute damage.
|-
|{{anchor|eggplasma}}[[#eggplasma|Egg Plasma]]
|
* Infects with a xeno larva.
* Makes more of itself by draining blood.
|
* [[Researcher#HST|HST]] 4
|
{{:Chemical/Egg Plasma}}
|
|0,4
|
* 80
* 100
|
* Drains blood and replicates itself faster.
* '''(C)''' Makes you nervous.
|-
|{{anchor|neurotoxinplasma}}[[#neurotoxinplasma|Neurotoxin Plasma]]
|
* Not to be confused with the [[Drinks#neurotoxin|drink]].
* Deals 7 brain damage.
* Deals 1 toxin damage.
* Makes you high.
* Makes you hallucinate.
* Makes you jittery.
|
* [[Researcher#NRT|NRT]] 4
* [[Researcher#TOX|TOX]] 1
* [[Researcher#HLG|HLG]] 6
|
{{:Chemical/Neurotoxin Plasma}}
|
|0,4
|
* 30
* 50
|
* Deals 12 brain damage.
* Makes you stumble around.
* Makes you hallucinate more.
* Makes you more jittery.
* Makes you drowsy.
* Deals 2 toxin damage.
* '''(C)''' Knocks you out.
* '''(C)''' Deals 6 brain damage.
* '''(C)''' Applies the same effect as getting shot with [[Sentinel|neuro]].
* '''(C)''' Deals 4 toxin damage.
|-
|{{anchor|purpleplasma}}[[#purpleplasma|Purple Plasma]]
|
* Deals 2 brute damage.
|
* [[#BCD|BCD]] 2
|
{{:Chemical/Purple Plasma}}
|N/A
|0,4
|
* 30
* 50
|
* Deals 4 brute damage.
* '''(C)''' Deals 8 brute damage.
|-
|{{anchor|royalplasma}}[[#royalplasma|Royal Plasma]]
|
* Makes you addicted to itself.
* Deals 4 brute damage.
* Makes you hallucinate.
* Makes you high.
* Makes you jittery.
|
* [[Researcher#BCD|BCD]] 4
* [[Researcher#ADT|ADT]] 1
* [[Researcher#HLG|HLG]] 4
* [[Researcher#CIP|CIP]] 1
|
{{:Chemical/Royal Plasma}}
|N/A
|0,4
|
* 30
* 50
|
* Deals 1 brain damage.
* Deals 8 brute damage.
* Makes you stumble around.
* Makes you hallucinate more.
* Makes you more jittery
* '''(C)''' Deals 4 brain damage.
* '''(C)''' Knocks you out.
* '''(C)''' Deals 16 brute damage.
* '''(C)''' Makes you nervous.
|}

==Other==
This contains reagents that don't neatly fit into other categories.
{| class="wikitable unsortable" style="width: 100%;"
! style="width: 10%; margin: auto;" |Name
! style="width: 20%; margin: auto;" |Effect
! style="width: 12%; margin: auto;" |Properties
! style="margin: auto;" |Acquiring
! style="width: 5%; margin: auto;" |Ratio
! style="width: 5%; margin: auto;" |Meta- bolism
! style="width: 5%; margin: auto;" |OD
! style="width: 20%; margin: auto;" |OD effects
|-
|{{anchor|fertilizer}}[[#fertilizer|Fertilizer]]
|
* Usable as fertilizer for plants.
* Deals 0,5 toxin damage.
|
* [[Researcher#TOX|TOX]] 0,5
|
{{:Chemical/Fertilizer}}
|N/A
|0,1
|N/A
|N/A
|-
|{{anchor|plantbgone}}[[#plantbgone|Plant-B-Gone]]
|
* Kills xeno weeds.
* Kills normal weeds.
* Harms helpful plants in hydro trays too.
* Deals 1 toxin damage.
|
* [[Researcher#TOX|TOX]] 2
|
{{:Chemical/Plant-B-Gone}}
|5:5
|0,1
|N/A
|N/A
|-
|{{anchor|smoke}}[[#smoke|Smoke]]
|
* Creates smoke
|N/A
|
{{:Chemical/Smoke}}
|N/A
|N/A
|N/A
|N/A
|-
|{{anchor|flashpowder}}[[#flashpowder|Flash Powder]]
|
* Creates a bright light that lasts for a while.
|N/A
|
{{:Chemical/Flash Powder}}
|N/A
|N/A
|N/A
|N/A
|-
|{{anchor|blood}}[[#blood|Blood]]
|
* Spreads diseases if injected.
* Restores blood volume when injected into a human.
** Deals toxin damage if blood type is incorrect. (Just use O-)
|N/A
|
{{:Chemical/Blood}}
|N/A
|N/A
|N/A
|N/A
|-
|{{anchor|plasticide}}[[#plasticide|Plasticide]]
|
* Deals 1 toxin damage.
* Turns into plastic when mixed at a 20:10 ratio with [[#sulphuricacid|Sulphuric Acid]].
|
* [[Researcher#TOX|TOX]] 1
|{{:Chemical/Plasticide}}
|N/A
|0,01
|N/A
|N/A
|-
|{{anchor|serotrotium}}[[#serotrotium|Serotrotium]]
|
* Makes you sneeze, blink and cough.
|
* [[Researcher#ALG|ALG]] 2
|{{:Chemical/Serotrotium}}
|N/A
|0,2
|
* 30
* 50
|N/A
|-
|{{anchor|glycerol}}[[#glycerol|Glycerol]]
|
* Used for making nitroglycerin.
|N/A
|
{{:Chemical/Gylcerol}}
|4:1
|0,01
|N/A
|N/A
|-
|{{anchor|virusfood}}[[#virusfood|Virus Food]]
|
* No pathology on CM. So this is entirely useless.
* Satiates you.
|
* [[Researcher#NTR|NTR]] 2
|
{{:Chemical/Virus Food}}
|3:3
|0,2
|N/A
|N/A
|-
|{{anchor|thermite}}[[#thermite|Thermite]]
|
* Fire modifier.
* Deals 1 burn damage.
* Can be applied to walls either directly or with a spray bottle and then ignited to melt through them.
|
* [[Researcher#FUL|FUL]] 7
* [[Researcher#OXI|OXI]] 5
* [[Researcher#VIS|VIS]] 4
* [[Researcher#CRS|CRS]] 2
|
{{:Chemical/Thermite}}
|3:3
|0,2
|N/A
|N/A
|-
|{{anchor|spacecleaner}}[[#spacecleaner|Space Cleaner]]
|
* Cleans objects when splashed/sprayed on them.
* Use a spray bottle filled with it to clean a dirty microwave.
|N/A
|
{{:Chemical/Space Cleaner}}
|3:2
|0,2
|
* 30
* 50
|
* Unless there's some snowflake code tucked away in a deep dark corner of CM, this has no effects on OD.
|-
|{{anchor|cryptobiolin}}[[#cryptobiolin|Cryptobiolin]]
|
* Used for making spaceacillin.
|N/A
|
{{:Chemical/Cryptobiolin}}
|3:3
|0,2
|N/A
|N/A


|-
|{{anchor|fluorosurfactant}}[[#fluorosurfactant|Fluorosurfactant]]
|
* Turns into foam when mixed with [[#water|water]] at a 1:1 ratio.
|N/A
|
{{:Chemical/Fluorosurfactant}}
|5:5
|0,2
|N/A
|N/A
|-
|{{anchor|foamingagent}}[[#foamingagent|Foaming Agent]]
|
* Creates metal foam when 1u is mixed with 1u [[#polytrinicacid|polytrinic acid]] and 3u [[#aluminuim|aluminium]] or 3u [[#iron|iron]].
|N/A
|
{{:Chemical/Foaming Agent}}
|2:1
|0,2
|N/A
|N/A
|-
|{{anchor|ammonia}}[[#ammonia|Ammonia]]
|
* Used for explosives.
|N/A
|
{{:Chemical/Ammonia}}
|4:3
|0,2
|N/A
|N/A
|-
|{{anchor|hexamine}}[[#hexamine|Hexamine]]
|
* As above.
|N/A
|
{{:Chemical/Hexamine}}
|5:3
|0,2
|N/A
|N/A

|-
|{{anchor|diethylamine}}[[#diethylamine|Diethylamine]]
|
* Fertilizer.
|N/A
|
{{:Chemical/Diethylamine}}
|2:2
|0,2
|N/A
|N/A
|-
|{{anchor|blackgoo}}[[#blackgoo|Black Goo]]
|
* Gives you the zombie virus.
|
* [[Researcher#RAV|RAV]] 1
|{{:Chemical/Black Goo}}
|N/A
|100
|N/A
|N/A
|-
|{{anchor|dinitroaniline}}[[#dinitroaniline|Dinitroaniline]]
|
* A herbicide and pesticide mixture used in hydroponics
* Deals 1 toxin damage.
|
* [[Researcher#TOX|TOX]] 1
|
{{:Chemical/Dinitroaniline}}
|3:3
|0.2
|N/A
|N/A
|}

==Explosives and flammable chems==
This contains reagents that can be used for making explosives. They may be duplicates of ones already present in one of the previous tables.
{| class="wikitable unsortable" style="width: 100%;"
! style="width: 10%; margin: auto;" |Name
! style="width: 20%; margin: auto;" |Recipe
! style="width: 10%; margin: auto;" |Ratio
! style="width: 10%; margin: auto;" |Power
! style="width: 10%; margin: auto;" |Falloff
! style="width: 10%; margin: auto;" |Intensity
! style="width: 10%; margin: auto;" |Radius
! style="width: 10%; margin: auto;" |Duration
! style="width: 10%; margin: auto;" |Fire colour
|-
| [[#water|Water]]
|
{{:Chemical/Water}}
| 3:1
| 0
| 0
| -3
| 0
| 0
| N/A
|-
| [[#oxygen|Oxygen]]
| {{:Chemical/Oxygen}}
| N/A
| 0
| 0
| 0,75
| -0,08
| 0
| #58daff (light blue)
|-
| [[#copper|Copper]]
| {{:Chemical/Copper}}
| N/A
| 0
| 0
| 0
| 0
| 0
| #78be5a (green)
|-
| [[#hydrogen|Hydrogen]]
| {{:Chemical/Hydrogen}}
| N/A
| 0,15
| 0
| -0,5
| 0,2
| -0,5
| #b6f8ff (super light blue)
|-
| [[#carbon|Carbon]]
| {{:Chemical/Carbon}}
| N/A
| 0
| 0
| 0
| 0
| 1
| #ffd700 (gold)
|-
| [[#phosphorus|Phosphorus]]
| {{:Chemical/Phosphorus}}
| N/A
| 0
| 0
| 1
| -0,12
| 0,1
| #ffdba4
|-
| [[#lithium|Lithium]]
| {{:Chemical/Lithium}}
| N/A
| 0
| 0
| 0,35
| -0,01
| -0,1
| #ff356f (dark pink)
|-
| [[#thermite|Thermite]]
|
{{:Chemical/Thermite}}
| 3:3
| 0,5
| 1
| 0,3
| -0,08
| 0,9
| #ffb300 (orange)
|-
| [[#fuel|Welding Fuel]]
| {{:Chemical/Welding Fuel}}
| N/A
| 0,12
| -0,1
| 0,1
| -0,08
| 0,7
| #ff9900 (orange)
|-
| [[#hexamine|Hexamine]]
|
{{:Chemical/Hexamine}}
| 5:2
| 0
| 0
| 0
| 0
| 0,5
| #ff9900 (as above)
|-
| [[#napalm|Napalm]]
|
{{:Chemical/Napalm}}
| 3:1
| 0
| 0
| 0,45
| 0,06
| 0,75
| #D05006 (dark orange)
|-
| {{anchor|clf3}}[[#clf3|CLF3 (Chlorine Trifluoride )]]
|
{{:Chemical/Chlorine Triflouride}}
| 4:1
| 0
| 0
| 1,6
| -0,08
| -0,8
| #ff9300 (orange)
|-
| [[#methane|Methane]]
|
{{:Chemical/Methane}}
| 5:1
| 0,15
| 0
| -0,35
| 0,095
| 0,25
| #00a5ff (blue)
|-
| {{anchor|ammoniumnitrate}}[[#ammoniumnitrate|Ammonium Nitrate]]
|
{{:Chemical/Ammonium Nitrate}}
| 2:2
| 0,4
| 1,5
| 0,5
| 0
| -0,2
| #ff9900 (orange)
|-
| {{anchor|anfo}}[[#anfo|Ammonium Nitrate Fuel Oil]]
|
{{:Chemical/Ammonium Nitrate Fuel Oil}}
| 3:2
| 1
| -0,6
| 0
| 0
| 0
| N/A
|-
| {{anchor|nitroglycerin}}[[#nitroglycerin|Nitroglycerin]]
|
{{:Chemical/Nitroglycerin}}
| 3:2
| 1
| -0,5
| 0
| 0
| 0
| N/A
|-
| {{anchor|cyclonite}}[[#cyclonite|Cyclonite]]
|
{{:Chemical/Cyclonite}}
| 2:2
| 1,5
| -0,4
| 0
| 0
| 0
| N/A
|-
| {{anchor|octogen}}[[#octogen|Octogen]]
|
{{:Chemical/Octogen}}
| 4:2
| 2
| -0,2
| 0,4
| -0,02
| -0,2
| Orange 
|-
| {{anchor|potassiumhydroxide}}[[#potassiumhydroxide|Potassium Hydroxide]]
|
* Explodes INSTANTLY and can't be stabilized. Don't use this. It's garbage.
{{:Chemical/Potassium Hydroxide}}
| 2:1
| 0,5
| 0
| 0
| 0
| 0
| N/A
|-
| [[#phoron|Phoron]]
| {{:Chemical/Phoron}}
| N/A
| 0
| 0
| 0,4
| 0,05
| -0,8
| #e01e1e (red)
|-
| [[#potassiumchloride|Potassium Chloride]]
|
{{:Chemical/Potassium Chloride}}
| 2:2
| 0
| 0
| 0,1
| 0
| 0
| #800080 (purple)
|-
| {{anchor|salt}}[[#salt|Table Salt]]
|
{{:Chemical/Table Salt}}
| 1:1
| 0
| 0
| 0,1
| 0
| 0
| #ffff00 (yellow)
|-
| {{anchor|stickynapalm}}[[#stickynapalm|Sticky Napalm]]
|
{{:Chemical/Sticky Napalm}}
| 1:1
| 0
| 0
| 0,2
| 0,5
| 0,5
| #f8e3b2 (barley white)
|-
| {{anchor|hcnapalm}}[[#hcnapalm|High-Combustion Napalm]]
|
{{:Chemical/High-Combustion Napalm}}
| 1:1
| 0
| 0
| 0,8
| 0,1
| 0,5
| #742424 (dark red)
|}

<br>

= Additional User made information=
* [https://cm-ss13.com/forums/showthread.php?3414-Magnus-Opus-on-Reasearch-by-Cory-Paulson Magnum Opus on Research] by Cory Paulson

Guide to Git

2024-03-26T20:54:14Z

Drulikar: Update latest byond version working with language server.

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Downloading Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

=== Step 3: Download Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of https://github.com/[YOURUSERNAME]/cmss13. Select a folder to download the repo into, and let it run. It may take awhile.

=== Step 4: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

Also - search for and install GitLens. It makes using the source control features of Visual Studio Code much easier.

[[File:recommended_extensions.png|400px]]

=== Step 5: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* Add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

NOTE: As of writing, only up to BYOND 515.1633 is functional with the language client server (dm-langserver 1.8.0+19 using auxtools commit: v2.3.3).
[[File:Language Client Settings.png|655x655px]]

=== Step 6: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

=== Step 4: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You can give it a commit message on the box with “Message”, and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 5: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your branch will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

Dropship Pilot

2024-03-17T07:51:56Z

Drulikar: Separation of PO

#REDIRECT [[Pilot_Officer]]

Gunship Pilot

2024-03-17T07:43:06Z

Drulikar: Separation of PO

#REDIRECT [[Pilot_Officer]]

Lurker

2024-02-23T00:48:34Z

Drulikar: /* Vampire */ Updated values to reflect 5625 and 5753

{{XenoPageHeader
|headerbgcolor = black
|headerfontcolor = white
|tiertype = ALIEN - TIER 2
|imagebgcolor =
|img = Alien-Warrior.png
|castetitle = Lurker
|evolves_from = [[Runner]]
|evolves_to = [[Ravager]]
|role = A highly mobile alien which packs a punch, good for ambushing and general harassment of the marines supply lines.
|guides = No External Guides.
}}
== General Information ==
The '''Lurker''' is a large step up from the [[Runner]] that precedes it. What it loses in speed and agility is largely gained in becoming a fearsome and destructive force, capable of '''effortlessly slaughtering any single [[Marines|tallhost]] that it finds wandering alone''', where a Runner might have needed to go for a long, sloppy brawl to secure a kill.
<br><br>
The Lurker is not as fast as the Runner and its '''<code>Pounce</code>''' is more cumbersome, having him pin down his target instead of simply flooring him, as well as the need to be cloaked, for the pounce to actually work. However, its attack quickly becomes devastating, capable of tearing a tallhost apart once subdued, meaning that they will usually stand no chance if caught with their pants down. Its health is nothing to laugh at, although it will still go down quickly if focus fired by a group.
<br><br>
[[File:Hunt_stalk_HUD.gif|thumb]]The Lurker loses its ability to hide under objects, being a caste of much greater stature, but it gains a fascinating ability to '''Cloak''' on activation, for 30 seconds. While the Cloak is far from perfect and will easily be spotted when moving or hiding on a bright background, it will allow the Lurker to hide in far more spots, and to spring ambushes even in the open if it finds a good spot.
<br>

== Playing as a Lurker ==
As a Lurker, you lose your ability to easily dodge attacks in exchange for more solid health and a greater attack. As such, you become more of an ambush caste, with an ability to skirmish and seriously wound tallhosts using hit and run attacks. Your '''Cloak''' helps you to set up ambushes, meaning you can wait for the perfect moment to strike instead of making a risky sprint into a potential target, which could reveal an off-screen group accompanying them, a turret, anything that could ruin your day.
<br><br>
While you keep your ability to '''<code>Pounce</code>''', it is important to note that its purpose shifted from a disarming pounce that you and the tallhost will recover from quickly, to a disabling pin that will cause both you and your target to be floored for a significant duration, allowing you to tear them apart while they lay defenseless on the floor. This does mean however that pouncing on someone in the middle of a group will almost certainly get you killed, so avoid it at all costs.
<br><br>
Your '''Cloak''' is a fantastic tool. While it is not as reliable as the Runner's Hiding to conceal you for long periods of time, it can allow you to blend into the environment in a pinch to find and subdue a target. The fewer tallhosts expect you, the less they will think to carefully scan their surroundings for that one shimmer in the distance. And remember that cloaking will make you much faster, but it only lasts for 30 seconds. If tallhosts are tracking you down, they will probably see through your cloak unless you find an excellent spot.
<br><br>
Should you find yourself in direct combat, you are still a formidable foe, although you will not take as many shots as your bigger sisters to knock down. It is important that you try and run on the flanks as much as possible, using your Cloak wisely to close the distance without being sprayed down by gunfire from alert and ready Marines.

== Abilities ==

{| class="wikitable mw-collapsible"
! style="background-color:#423042;" width=150|<span style="color:white;">Abilities:</span>
! style="background-color:#423042;" |<span style="color:white;">Description:</span>
|-
![[File:Xeno_Rest.png]]<br>Rest
|Used to rest and get up. Aliens heal faster when resting on weeds.
|-
![[File:Regurgitate.png]]<br>Regurgitate
|{{Devour}}
|-
![[File:Pounce.png]]<br>Pounce
|Pounce at target, pining the victim on the ground and causes them to drop their weapons, but only if you are invisible. Lasts longer than a Runner's pounce, but also makes you immobile for a short duration while you pin the target down.

Costs 10 plasma, cooldown: 7 seconds.
|-
![[File:Turn-Invisible.png]]<br>Turn Invisible
|Turns you partially invisible for 30 (thirty) seconds. While invisible, your movement speed is drastically increased. The further you are from friendly a alien, the faster you are. If you attack or pounce on a target, your invisibility will wear off.

Costs 10 plasma, cooldown: 30 seconds.
|-
![[File:Crippling-Strike.png]]<br>Crippling Strike
|The next target you slash will receive extra damage and be slowed down. This will only work on resting targets. If you attack a target standing while the ability is active, it will use up the strike and the target won't receive extra damage nor the slow down.

Costs 50 plasma, cooldown: 12 seconds.
{{Tail Stab}}

|}

== Attainable Strains==
{| style="border: 2px solid black;
! style="background-color:#423042; text-align:center;"|'''Strain:'''
|-
|style="width:125px; border: 2px solid black; border-bottom: 2px solid black; padding: 5px; text-align:center;" |
'''[[Strains|Vampire]]'''
|}
===Strain Abilities===
<br>
====Vampire====
* '''Health''': 390
* '''Armor''': 20
* '''Slightly faster movement speed - just under that of a cloaked lurker, but always active.'''
{| class="wikitable mw-collapsible"
! style="background-color:#423042;" width=150|<span style="color:white;">Abilities:</span>
! style="background-color:#423042;" |<span style="color:white;">Description:</span>
|-
![[File:Pounce.png]] <br> Rush
|A four-tile pounce that causes your targets screen to shake. This ability does not stun them.

Cooldown: 6 seconds.
|-
![[File:Spike_spray.png]]<br>Flurry
|An attack that has a range of 1x3 tiles, dealing 30 damage per target and healing you for 30 HP. A short slow is also applied to you upon landing it. This will hit a random limb.

Cooldown: 3 seconds.
|-
![[File:Pierce.png]]<br>Tail Jab
|An attack dealing 30 damage to the chest, alongside pushing the target back. If you click on the sprite of your target with it, it will deal an extra 15, for a total of 45 damage to the chest, alongside throwing them back. If they impact an obstacle such as a wall, window, door or barricade, they will take more damage and will temporarily be stunned.
(Note: for utility can instantly break windows).

Cooldown: 7 seconds.
|-
![[File:Headbite_Ability_Icon.png]]<br>Headbite
|A high-damage attack that bypasses all armor, instantly killing your target and healing you for 150 HP. Requires your target to be unconscious and adjacent to you, and has a 0.8 second windup before it will hit them.
|}

== Lurker Tactics ==
* Your '''Cloak''' is best used when stationary and on a dark background. Moving will not make you any more visible, but humans will have a far easier time spotting your shimmer if it's moving across tiles. Darkness also works fairly well in concealing you, although it is not necessary. Since the tiling used in colonies is often bright outside of bathrooms, maintenance areas, and high-security areas, you might have trouble finding spots to hide in buildings.

* Isolated targets are in essence free kills for you. A single Pounce will disarm them and floor them for long enough for you to start the fight with a handful of slashes. At this point, they might have a window to fight back, but they will undoubtedly be wounded. Make a simple evasive maneuver to avoid CQC weapons like buckshot shotguns and pounce again, and you should have them in the bag.

* If you do need to brawl against a group, or partake in a massive fight, only use your Pounce for evasive maneuvers, and use your regular speed to get close to Marines and slash them. Of course, it is heavily recommended to approach from the rear or sides.

*Your pounce can be used to quickly cover distance, and will let you leap into windows immediately instead of having to climb on top of them. While still not as smooth as a runner simply running over it, this will allow you to travel faster. Be careful though, pouncing into a window frame will stop your movement, so if you do it to attack a host behind it will cause you to stop on the frame. If your target has a shotgun this can end very poorly for you.

== Lurker Evolution ==

Lurkers can only '''Evolve''' into one possible caste, being the Ravager:

* The [[Ravager]] is the ultimate combat form of the [[Runner]]'s evolution tree. While it loses some more speed, it grows into a large and powerful Alien, capable of utterly destroying humans even under fire. Your Pounce will no longer pin tallhosts, instead of knocking them off their feet, allowing you to come in for a devastating blow immediately. Your attacks also gain an increased damage, allowing you to unleash devastating blows. You also gain some resistance to explosive stuns (depending on the strain) and immunity to damage from fire, allowing you to engage into fights that would be ill-advised to even the most seasoned Lurkers.

== Lurker Stats ==
{{XenoSkills
|meleelow=4
|meleehigh=4
|health=5
|plasmaregen=8
|plasma=4
|explosiveresist=2
|speed=8
}}
You can learn more about alien stats [[Xenomorph Stats|here]].

[[Category:Alien Castes]]

Guide to Git

2024-02-03T22:32:25Z

Drulikar: /* Mapping Conflicts */

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Downloading Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

=== Step 3: Download Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of https://github.com/[YOURUSERNAME]/cmss13. Select a folder to download the repo into, and let it run. It may take awhile.

=== Step 4: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

Also - search for and install GitLens. It makes using the source control features of Visual Studio Code much easier.

[[File:recommended_extensions.png|400px]]

=== Step 5: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* Add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

NOTE: As of writing, only up to BYOND 514.1589 is functional with the language client server.
[[File:Language Client Settings.png|655x655px]]

=== Step 6: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

=== Step 4: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You can give it a commit message on the box with “Message”, and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 5: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your branch will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM) to look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

Guide to Git

2024-02-03T22:27:46Z

Drulikar: Elaborated on merge conflicts and added information about DMI conflicts.

= Guide to Git =

== Setting up your Coding Environment ==

Though you can use DreamMaker, and external Git software, for modifying your code and maps, all modern SS13 tooling is set up for Visual Studio Code, so it is highly recommended. You can jump to variable definitions, procs and atoms with ease.

=== Step 1: Downloading Visual Studio Code ===

Visual Studio Code is a free code editor (from Microsoft) that you can use to edit, test and publish your code to GitHub.

You can download it from https://code.visualstudio.com/ and run the installer.

=== Step 2: Forking the Repository ===

Go to https://github.com/cmss13-devs/cmss13, and at the top right, hit “Fork” - you’ll need a GitHub account for this.

[[File:fork.png|400px]]

Follow the prompts that come up, and you’ll have your own copy of the code on GitHub.

=== Step 3: Download Git ===

You’ll need Git installed to make any changes to the repository. Download it from https://git-scm.com/downloads.

Then, on Visual Studio Code, under the Source Control tab on the left bar - the third option down, you should be presented with the option to “Clone Repository”.

[[File:clone_repo.png|400px]]

Paste the URL of your fork into the box that pops up - this should be in the format of https://github.com/[YOURUSERNAME]/cmss13. Select a folder to download the repo into, and let it run. It may take awhile.

=== Step 4: Download Extensions ===

These extensions to Visual Studio Code will allow the program to read DreamMaker code intelligently and allow you to navigate through the code faster.

You can get them by clicking on the extensions tab - probably the fourth or fifth option, it looks like three boxes with a fourth being added - and downloading all the “Recommended” extensions.

Also - search for and install GitLens. It makes using the source control features of Visual Studio Code much easier.

[[File:recommended_extensions.png|400px]]

=== Step 5: Configuring Language Client ===
Debugging features like breakpoints rely on the language server to be installed and working.

* Search for "@enabled Language Client" in extensions
* Click the gear and then Extension Settings
* Enable Auto Update
* Add/update the Byond Path to your BYOND installation folder (will be a folder with unist.exe and 6 other folders)
* Restart Visual Studio Code

Auto Update will ensure you have the latest version of the language server installed in a temporary folder for Visual Studio Code. A correct path to the BYOND installation folder will allow the language server to compile and parse the code.

NOTE: As of writing, only up to BYOND 514.1589 is functional with the language client server.
[[File:Language Client Settings.png|655x655px]]

=== Step 6: Finishing Up ===

You’ve now got a complete clone of the CM-SS13 codebase on your local computer!

== Making a Change ==

All changes you make to the code must be done on a new branch.

A branch is another version of your codebase - made from your “master” branch - which should be identical to the “master” branch present on the main repo - which changes can be made to without affecting your “master” branch.

A “commit” is a save of your changes to the code you’ve made. Every time you “commit” your changes to the branch, you are saving all your changes made so far. All code must be “committed” before it can be sent to the main repository.

To start with making changes, you must make a new branch on your forked repository, from your master branch. Your master branch should never be committed to, and should be a clean state.

Every PR you make should have a new branch. This allows for commits you make on different branches to not affect your other branches, letting you work on multiple projects at once.

=== Step 1: Making a New Branch ===

Press Control + Shift + P to bring up the Command Pallet. This allows you to control Visual Studio Control easily, but we want the command “Create branch from...”. Type that in and press enter to run it. Give your branch a name - like new-helmet. Select which branch to make it from - that will be your master branch.

[[File:create_branch_from.png|400px]]

Then, switch to this branch. You can do this at the bottom of the Source Control tab, under the Branches title - you might have to click on it to show all your branches. Right click on your new branch, and select the option to switch to it.

[[File:switch_branch.png|400px]]

Now, you can make whatever changes you like, and you can commit them to this branch without altering your master branch.

=== Step 2: Modifying the Code ===

Now, if you make any change to any file within the repo, Git will notice and add it to the modified files in the Source Control tab.

You can make a simple change - such as altering an item description - just to see your code changes reflected in game. To find an item, use the Search tab on the left - the magnifying glass - and type in the name or description if the item as it is in game.

[[File:searching.png|400px]]

Once you’ve made this change, it’ll be noticed at the top of the Source Control tab.

[[File:changes.png|400px]]

=== Step 3: Testing your Code ===

Press F5 - this will start your code with the debugger attached. This will automatically pause the server and tell you when an error - usually known as a runtime - occurs.

You can press Control-F5 to start without the debugger.

Then, at the bottom right of your Windows interface, click the chevron to view your hidden processes. Click on the green DreamDaemon circle, and you can see the server process that has booted up. Then, on the World tab at the top, press Join. This will log you in to the server, where you will automatically have full Admin permissions.

Find your item in game - or spawn it in with the admin game-panel - and it should have the changes you’ve made in the code. If it doesn’t- you probably didn’t save the file. Terminate the server using the stop button on Visual Studio Code or by right clicking on the DreamDaemon process and pressing Stop.

=== Step 4: Committing your Changes ===

At the top of the Source Control tab, your modified file should be under “Changes”. Hover over the file name you have modified, and press the Plus symbol - or do the same over the Changes button to “stage” your changes.

[[File:example_commit.png|400px]]

Once your changes have been “staged”, they have been selected to be committed. You can give it a commit message on the box with “Message”, and press the tick at the top to commit those changes.

[[File:example_stage.png|400px]]

Once this has been completed, you’ve committed your changes locally - but they have not been published to your GitHub fork.

=== Step 5: Publishing to GitHub ===

This is quite simple. On the Source Control tab, you should now see the “Publish Branch”. This will publish your branch, along with your changes, to your fork on GitHub. You can navigate to it on the web to see these changes.

[[File:publish_branch.png|400px]]

If you make any further changes to this branch and commit them, you will see the “Sync Changes” option instead. This does the same thing - “pushing” all your changes to your fork on GitHub.

[[File:example_sync.png|400px]]

== Making a Pull Request ==

A “pull request” is a *request* for the main repository to *pull* - or more accurately, merge - the contents of your branch into the master branch. This process allows for code to be tested and reviewed by maintainers/developers, before being merged into the master branch.

=== Step 1: Navigating the Web Interface ===

Head to your repository on GitHub - not the main CM-SS13 repo. Then, click on “master” and type in the name of your branch.

[[File:navigating_github_create_pr.png|800px]]

Hit “Contribute” on the right, and it’ll bring up the option to Create Pull Request. Clicking on this automatically sets the merge as being from your branch to the master branch at the main CM-SS13 repository.

[[File:auto_merge.png|800px]]

Hopefully, there's no merge conflicts, and it gives the happy green "Able to automatically merge" - however, if someone else has changed code you're changing in your PR after you made the branch for this feature, you'll need to manually deconflict the files. Read on for more about merge conflicts.

=== Step 2: Creating the Pull Request ===

Give your PR a good title - this will be the message of the commit to the main branch containing all your code.

[[File:title.png|800px]]

Then, fill in the PR description, including a descriptive changelog. Put your BYOND username next to the first :cl: to ensure you are accurately credited.

[[File:changelog.png|800px]]

Then, hit Create Pull Request (or don’t, if you’re uselessly changing one description as a test).

[[File:create_pull_request.png|800px]]

=== Step 3: Code Review ===

GitHub will automatically run some tests on your code, which may fail, resulting in you having to change your code. The developers will review your code, and may also request changes. That'll look like this.

[[File:github_checks.png|800px]]

In order to carry out the changes, simply make the changes on your branch on your local repository, and press “Sync Changes”, this will automatically update the PR.

If a developer has marked your PR as a draft, you will have to mark it as being ready for review. You can do this at the bottom of the web interface on your PR.

== Staying in Sync ==

As other PRs are merged into the repository, your branch will slowly become out of date. This will become an issue over time, as you modify code that has been changed by another recent PR, and you find conflicts that didn’t need to happen.

To avoid this, regularly go to your master branch of your fork on the web interface, and press “Sync fork” and "Update branch", to add all the commits recently merged to your fork.

[[File:update_branch.png|800px]]

Then, on Visual Studio Code, you can “Sync Changes” to update your local copy of the master branch.

Do this regularly to ensure you don’t fall out of date with any changes.

= Appendix =

== Merge Conflicts ==
When your PR is conflicting with master, this means that there are places that both you and someone else have both altered and a decision has to be made to decide what that file or line of code should be. To begin the process to resolve this, you need to merge upstream/master into your branch. (VSC Source control has an Add Remotes option in the Remotes section of Source Control where you can add the link to the .git of the main repository). This will initiate any merge hooks automatically explained more below.

=== Mapping Conflicts ===

Sometimes mapping conflicts can be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). Should a single tile be altered by both you and someone else, a mapping conflict marker will be placed in that location that will cause lint errors and yell in chat. This will help during mapping conflicts by marking areas that are conflicting, allowing you to open an editor (such as StrongDMM), look for the conflict markers and resolve the issue.

Should a conflict like this occur, you should then open the map editor (StrongDMM) and look for the conflict markers. In text, it will look like the conflict has entirely disappeared - but it *hasn’t* - the MapMerger has just automatically dumped everything from the conflicting branches together in a mess that *you* have to fix.

=== DMI (Icon File) Conflicts ===

Just like with mapping conflicts these conflicts can often be handled automatically via a merge hook. Install the git hooks in tools/hooks by hitting “Install.bat” (Windows) or "Install.sh" (Linux). More often than not any new icons that someone else added will just be appended to the end of the file. But if both you and someone else alter the same icon_state of something, that will have to be manually resolved. In this situation just open up the DMI file in either Dreamaker or VSC's DMI Editor and adjust it as needed. Ultimately use the IDB (Icon Diff Bot) checks to double check you haven't unintentionally removed a icon_state someone added.

=== Code Conflicts ===

There is no hook to automatically handle code conflicts. Find the conflict markers in conflicting files indicated with a bunch of >>>>>>>>> and <<<<<<<<<. VSC should make this obvious, and in some cases, deconflict the files itself. Where it fails to do so, you will need to remove the conflict markers and add the code together from both branches as applicable. Be sure to test if the changes work. For more information see https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts

== Glossary ==

=== Branch ===

A version of your fork that you can freely commit changes to without affecting other branches.

=== Commit ===

A change to a branch, can be of any size from a single space added to one file to completely rewriting the entire repository.

=== Fork ===

A copy of the CM-SS13 repository that you own, and can make whatever changes to that you like without impacting the main repo.

=== Repository ===

Often known as a repo. Ours contains all of the code, maps and assets for CM-SS13.

=== PR ===

Pull Request - a request for the main repository to merge the changes present in one of the branches of your fork into the master branch of the main, upstream repository.

=== Merge ===

Where all the commits from a branch are applied to another branch. For example, merging your origin branch containing a new feature to an upstream master branch.

=== Merge Conflicts ===

Where two branches from separate contributors have touched the same code, when one of them is merged, you will have a conflict preventing automatic merging. This involves manually fitting the code together, allowing both changes to exist without overwriting either.

=== Remote ===

A remote is a version of your repository that is not stored on your computer - such as on GitHub. This includes both your fork and the upstream, main CM-SS13 repo.

=== Origin ===

This will be your fork of the CM-SS13 repository.

=== Upstream ===

The upstream of your fork will be the main CM-SS13 repo. Think of changes flowing down a stream from the main repo to your fork when you “Fetch Upstream”.

=== Git ===

The version control system used by CM-SS13, allowing us to synchronise changes being made by many different contributor - and easily go back if something goes wrong.

=== Diff ===

Shows the changes between the current copy of the code and the new code that you have committed.

=== VSC / VS Code ===

Visual Studio Code, the text editor we use for DM development.

Surgery

2024-01-21T02:16:46Z

Drulikar: Added information about Surgery Failure Penalties.

==Tools of the Trade ==
{| class="wikitable"
!Tool
!Function
|-
|[[File:1Scalpel.png]]<br>'''{{anchor|Scalpel}}[[#Scalpel|Scalpel]]'''||Used for cutting through flesh. Has three laser-augmented variants of differing quality, each with a percentage chance to create a bloodless incision instead.<br>'''Improvised equivalents:''' PICT system[[File:The_PICT System.png|32px]], bayonet[[File:Autowiki-M5 'Night Raider' bayonet.png|32px]], kitchen knife[[File:Kitchen_Knife.png|32px]], or glass shard[[File:Shard.png|32px]]
|-
|[[File:1Incision_manager.png|64px]]<br>'''{{anchor|Incision Management System}}[[#Incision Management System|Incision Management System]] (IMS)'''||Used for cutting through flesh, skips bleeder clamping and organ rearranging. Basically acts as a scalpel, hemostat, and retractor in one step during the initial incision. Only functions as a scalpel in steps after the first. (Available in the surgical theatre on Solaris Ridge)
|-
|[[File:1Hemostat.png]]<br>'''{{anchor|Hemostat}}[[#Hemostat|Hemostat]]'''||Used to stop bleeding during an operation, or to remove foreign and undesirable objects from a patient's body. Also used to repair the brain by removing chips of bone from grey matter.<br>'''Improvised equivalents:''' wirecutters[[File:Wirecutters.png|32px]] for all of the above uses, a kitchen fork [[File:Kitchen Fork.png|32px]] for removing objects and brain repair, or cable coil [[File:CableCoils.png|32px]] if you are only trying to clamp bleeders during an operation.
|-
|[[File:1Bone Setter.png]]<br>'''{{anchor|Bone Setter}}[[#Bone Setter|Bone Setter]]'''||Used for setting bones back into place. If used on a bone that is not broken then you will break it.<br>'''Improvised equivalents:''' wrench[[File:Wrench.png|32px]] or maintenance jack[[File:Maintenance Jack.png|32px]]
|-
|[[File:1Bone-Gel.png]]<br>'''{{anchor|Bone Gel}}[[#Bone Gel|Bone Gel]]'''||Used for repairing broken/shattered bones, both in case of fracture and resealing cut ribcages & skulls.<br>'''Improvised equivalents:''' screwdriver[[File:Screwdriver.png|32px]]
|-
|[[File:1Retractor.png]]<br>'''{{anchor|Retractor}}[[#Retractor|Retractor]]'''||Used for widening incisions and re-arranging organs, and moving cut ribcages & skulls. '''Most scalpels and scalpel substitutes can widen incisions in place of a retractor or one of its substitutes, albeit at a much slower rate.''' When prying open bones, there is a small chance that the ribcage or skull will suffer a fracture even if this step is performed correctly. <br>'''Improvised equivalents:''' crowbar[[File:Crowbar.png|32px|]] or maintenance jack[[File:Maintenance Jack.png|32px]]
|-
|[[File:1Cautery.png]]<br>'''{{anchor|Cautery}}[[#Cautery|Cautery]]'''||Used for sealing incisions in a patients skin. Burns skin together.<br>'''Improvised equivalents:''' cigarette[[File:Cig.png|32px]], lighter[[File:Lighter.png|32px]], or blowtorch[[File:Welder.gif|32px]]
|-
|[[File:Fixovein.png]]<br>'''{{anchor|Fix-O-Vein}}[[#Fix-O-Vein|Fix-O-Vein]]'''||Used for repairing veins and arteries, treating internal bleeding in the process. Also used to repair hematoma in the brain, treating severe brain damage.<br>'''Improvised equivalents:''' surgical line[[File:Surgical Line.png|32px]] or cable coil[[File:CableCoils.png|32px]]
|-
|[[File:1Saw.png]]<br>'''{{anchor|Circular Saw}}[[#Circular Saw|Circular Saw]]'''||Used for cutting through bones, particularly those in the ribcage and skull. Performing a bone cutting step on '''disarm''' intent will instantly complete the step at the cost of a guaranteed fracture to that region.<br>'''Improvised equivalents:''' bayonet[[File:Autowiki-M5 'Night Raider' bayonet.png|32px]], hatchet[[File:Hatchet.png|32px|]] , or machete[[File:Machete.png|32px]]
|-
|[[File:Advtraumakit.png|64px]]<br>'''{{anchor|Advanced Trauma Kit}}[[#Advanced Trauma Kit|Advanced Trauma Kit]]'''||Used to repair all organs except for the brain and eyes.<br>'''Improvised equivalents:''' roll of gauze[[File:Gauze.png|32px]]
|-
|[[File:Surgical Line.png|64px]]<br>'''{{anchor|Surgical Line}}[[#Surgical Line|Surgical Line]]'''||Used to suture damaged flesh together, treating excessive brute damage. It can also be used to close incisions in place of a cautery.<br>'''Improvised equivalents:''' Fix-O-Vein[[File:Fixovein.png|32px]] or cable coil [[File:CableCoils.png|32px]]
|-
|[[File:Synth_Graft.png|64px]]<br>'''{{anchor|Synth Graft}}[[#SynthGraft|Synth-Graft]]'''||Used to graft severely burned flesh, treating excessive burn damage.<br>'''No improvised equivalents.'''
|-
|[[File:The_PICT System.png|64px]]<br>'''{{anchor|PICT Systerm}}[[#PICT Systerm|PICT System]]'''||The Precision Incision and Cauterization Tool uses a high-frequency vibrating blade, laser cautery, and suction liquid control system to precisely sever target tissues while preventing all fluid leakage. Despite its troubled development program and horrifying pricetag, outside of complex experimental surgeries it isn't any better than an ordinary twenty-dollar scalpel and can't create a full-length incision bloodlessly.

'''Improvised equivalents:''' scalpel[[File:1Scalpel.png|32px]] and all scalpel substitutes (see above)

|-
|[[File:Surgical Drill.png|64px]]<br>'''{{anchor|Surgical Drill}}[[#Surgical Drill|Surgical Drill]]'''||Used to open holes in the thoracic wall to access implant cavities, whether implanting a new object from scratch or removing a deeply-embedded foreign body (such as a monkey cube...)

'''Improvised equivalents:''' a pen or a metal rod

|}
* Improvised tools perform surgery slower compared to their ideal counterparts and apply a risk of failure mitigated by your surgical skill. The severity of the speed penalty scales on how unsuited the tool is. A bayonet is a much better substitute for a scalpel than a glass shard, for example.
* In addition to the speed penalty, an improvised PICT will spray acidic blood all over you and your patient, dealing burn damage to the patient's body as well as significant organ damage to the heart, lungs, and liver.
<br><br>

== Preparing for Surgery ==
=== Tools ===
Before you begin to operate, you should make sure you have all the tools you will need. Occasionally a surgeon will accidentally pocket a tool, or a deploying field surgeon will grab tools out of an operating theatre.

Specifically designed surgical tools are the best, but there are a variety of substitutes; some tools can be used outside of their intended role, and others can be replaced with improvised substitutes.

<small>
* The equipment on the Almayer is adequate, but sometimes marines will find better tools while deployed. If someone asks if you'd like an Incision Management System, the correct answer is "yes please".
</small>

<br>

=== Surgical Surface===
The second requirement is a place to work. Some surgeries can be performed on a standing patient, and it doesn't matter where you perform them. Most, however, need a decent surface to work on.

The patient doesn't necessarily need to be buckled - having them on the same tile will do. However the speed modifier is not applied if they aren't buckled.
If a surface isn't ideal, the surgery will take longer - and possibly a lot longer.

Locations, namely medical tents, can also provide some benefits to the surgery speed and pain reduction required.

<small>
* The ideal surface for surgery is a proper operating table. [[File:Operating_Table.png|32px]] This is designed for surgery and has a built-in anesthetic system for patients buckled to it. '''This is the only surface that can be used for extracting xenomorph larvae.'''

* The next best thing is a portable surgical bed. [[File:FieldSurgicalBed.png|32px]]

* The surfaces that are better than nothing are beds, [[File:Bed.png|32px]] roller beds, [[File:RollerBed.png|32px]] tables, [[File:Table.png|32px]] and window frames. [[File:Window_Frame.png|32px]]

* The worst surfaces are floors and Med-Evac stretchers, [[File:Med_Evac_Stretcher.png|32px]] which are not designed for surgery, and trying to work with their fittings in their way is as hard as no surface at all.
</small>

<br>

=== Surgery Failure Penalties ===
Improvised tools and poor working conditions contribute to a penalty system that increases the risk of failure, but this penalty is mitigated by your surgical skill.
{| class="wikitable"
!Tool Suitability
!Penalty
!
!Surface Suitability
!Penalty
!
!Skill Compensation
!Penalty
!
!Penalties
!Chance of Failure
|-
|Ideal
|0
|
|Ideal
|0
|
|Novice
|0
|
|0
|0%
|-
|Suboptimal
|0
|
|Adequate
|0
|
|Trained
| -1
|
|1
|5%
|-
|Subsitute
|0
|
|Unsuited
|1
|
|Expert
| -3
|
|2
|25%
|-
|Bad Substitue
|1
|
|Awful
|2
|
|Max
| -3
|
|3+
|50%
|-
|Awful
|2
|
|
|
|
|
|
|
|
|
|}
For example, performing internal bleeding surgery, skipping clamp bleeders step, by a corpsman on a roller:
{| class="wikitable"
!Step
!Tool Penalties
!Surface Penalties
!Skill Mitigation
!Total Penalties
!Chance of Failure
|-
|Knife - Incision (Pre-op)
|0 (Subsitute)
| - (Lying not required)
|0 (Novice)
|0
|0%
|-
|Knife - Expose (Pre-op)
|2 (Awful)
| - (Lying not required)
|0 (Novice)
|2
|25%
|-
|Surgical Line - Fix Vein (IB)
|0 (Subsitute)
|1 (Unsuited)
|0 (Novice)
|1
|5%
|-
|Surgical Line - Suture (Post-op)
|0 (Ideal)
| - (Lying not required)
|0 (Novice)
|0
|0%
|}
For example, performing internal bleeding surgery, skipping clamp bleeders step, by a surgeon on a roller:
{| class="wikitable"
!Step
!Tool Penalties
!Surface Penalties
!Skill Mitigation
!Total Penalties
!Chance of Failure
|-
|Shard - Incision (Pre-op)
|2 (Awful)
| - (Lying not required)
| -1 (Trained)
|1
|5%
|-
|Shard - Expose (Pre-op)
|2 (Awful)
| - (Lying not required)
| -1 (Trained)
|1
|5%
|-
|Surgical Line - Fix Vein (IB)
|0 (Subsitute)
|1 (Unsuited)
| -1 (Trained)
|0
|0%
|-
|Surgical Line - Suture (Post-op)
|0 (Ideal)
| - (Lying not required)
| -1 (Trained)
| -1
|0%
|}

=== Anesthetic ===
Surgery is a painful experience, and patients find it difficult to hold still while feeling someone cut into their flesh, which tends to frustrate everyone involved. There are two ways around this: an unconscious (or dead) patient, or powerful painkillers.

Anesthetic (with tank and mask or using the surgery table's integrated anesthesia setup) is a simple and reliable way to render your patient unconscious.

<small>
* if the patient's lungs are ruptured, they will occasionally not breath in the anesthetic. Depending on the damage to the lungs, they will either occasionally breath in the anesthetic or it won't work at all. Therefore, you will have to give the patient the anesthetic via Injection, until his lungs are not ruptured anymore.
</small>

<br>

==== Operating Table ====
If you are using an operating table, place your patient on the table (grab your patient, then click the table with your grabbing hand selected). Then buckle them to it to connect the anaesthetic system (click hold and drag the patient to the operating table). After a short delay, your patient will be under general anaesthetic, which will allow you to operate safely.

<small>
*The operating table must have an anaesthetic tank attached to be able to put your patient to sleep.

* Click on the surgery table with an anaesthetic tank in hand to insert one.

* Click on the table with an empty hand when no patient is buckled to it to remove an existing one.

* If the tank runs out, simply replace it with a new one.
</small>

<br>

==== Anesthetic Tank and Medical Mask ====
If there is no available operating table then you can make the patient wear an anesthetic tank and medical mask and turn on its internals. Encourage your patient to don and activate the tank and mask themselves, as this is much faster than doing it yourself.

<small>
* It is advisable to remove the anesthetic tank and medical mask during the cauterizing step for maximum efficiency; the anesthetic takes a few seconds to wear off.
</small>

<br>

==== Painkillers ====
If you don't have anesthetic equipment or you just want to save time, you can give your patients [[Chemistry#Oxycodone|Oxycodone]] for quick surgeries without anesthetic (15-20U recommended). You will need to work quickly, though, as it wears off.

Different surgeries cause different amounts of pain. If Oxycodone isn't available, some painkillers are much better than none; a mixture of [[Chemistry#Tramadol|Tramadol]], [[Chemistry#Inaprovaline|Inaprovaline]] or [[Chemistry#Paracetamol|Paracetamol]] (Paracetamol and Tramadol are toxic when mixed - do not give them simultaneously) will make them less likely to flinch.

<small>
* Use your medical scanner to monitor your patient's painkiller levels and re-dose as necessary. Using painkillers instead of anesthetics can cause distress in the patient (screaming over the radio about getting operated on without anesthetics, standing up and trying to leave or fight back).
</small>

Now that the preparations are done, you can begin with the actual surgery.
<br><br>

== Surgeries ==
Surgeries are simple processes with a series of steps. Once these steps are memorized it should become effortless and routine to perform. Keep in mind that once you have mastery over the basics, it's a good idea to aim to be as fast and efficient as possible due to the importance of recycling casualties back into the fight, or even preventing them from dying in the case of [[#Foreign Object/Alien Embryo Removal|Foreign Object/Alien Embryo Removal]].

To perform surgery on someone, you must Toggle the Surgery Mode to be On. This can be bound to a hotkey in preferences. [[File:Surgery Button.png|32px]]
This will toggle the Help-Intent Safety preference, if you didn't have it already, preventing you from accidentally hurting people with objects when on help intent. You will be forced on to {{Intent|Help}} intent (top left, {{Key press|1}}) [[File:Intent-Wheel.gif]], which allows you to perform any surgeries.

<small>
* The patient must not be wearing any armor.

* Only one surgery can be performed on a given aim-location at a time.

* Once you complete a step in a surgery, you must finish the surgery before you can begin a different one.

* Failing or cancelling the first attempted step doesn't injure the patient unless done deliberately.

* Some steps can be skipped, if the conditions are right, sometimes including the first step.

* If you are in a rush, attempting surgery steps on {{Intent|Disarm}} intent (top right, {{Key press|2}}) [[File:Intent-Wheel.gif]] deliberately fails the step. For a handful of specific steps, this will quickly and violently complete the step at the expense of your patient's health. Useful when you need to do a critical surgery very quickly, or to save time if you're certain you know what you're doing. It isn't necessary to switch back to Help intent afterwards - that happens automatically. (You can use disarm intent to skip the widening incision with Scalpel or break the rib with Circular Saw)
</small>

<br>

=== Standing Patients and Self-Surgery ===
Some surgeries can be performed on a patient who's standing up. These surgeries aren't affected by the surface under the patient. These are marked as '''(STANDING)'''.

Some surgeries can be performed on yourself. As you need to be able to hold tools while you work, this means they have to be able to be performed on a standing patient, since people who're lying down can't handle objects. These are marked as '''(SELF)'''.

<small>
* If you're trying to work on a standing patient and can't begin a surgery that you know you should be able to, make sure that it doesn't need them to be lying down.

* Since it's difficult and awkward to work on your own body, self-surgery takes longer to do.

* You can't perform surgery on the same arm you're holding the tool with.

* Self-surgery requires you to use painkillers rather than anesthesia, since it's hard to work when unconscious.
</small>

<br>

=== Required Skills ===
Your character's training affects how quickly they can work and mitigates risk of failure due to improvised tool or unsuitable working condition penalties.

<br>

Some surgeries can be performed by anyone with any surgical training, but others need a more thorough education.

<br>

Medics, nurses, and pilot officers all have basic surgical training and can perform simple level 1 surgeries.

<br>

Doctors, chief medical officers, and synthetic units have more skills and can perform level 1 and level 2 surgeries.

<br>

You may occasionally see Professor DUMMY, the medical mannequin. This is a sophisticated training tool designed to realistically simulate any wound. Real patients are more difficult to perform surgery on - a medic may be able to set Professor DUMMY's broken ribs, but that doesn't mean they can do it on a real patient in the field. (You can create an ahelp to ask admins to spawn you in a Professor DUMMY)

<br>

==== Level 1 Surgeries ====

{| class="wikitable"
!Surgery:
!Description:

|-
|{{anchor|Suture wound}}[[#Suture Wound|Suture Wound]] (Everywhere except mouth/eyes.) '''(STANDING - SELF)'''
|Suture and tend a wound that has brute or burn damage on it. This will heal 10 brute on the targeted area when a surgical line is used, and will heal 10 burn if a synth graft is used. This will loop until half of all damage on the area has been fixed.
*Tend to the damaged brute wound. [[File:Surgical Line.png|64px|link=|Surgical Line]]
*Tend to the damaged burn wound. [[File:Synth_Graft.png|64px|link=|Synth Graft]]
|-
|{{anchor|Foreign Object Removal}}[[#Foreign Objectl|Foreign Object]] (Everywhere except mouth/eyes.)
|Removal of unknown objects, such as shrapnel or implants from the body.
*Incision Management System. [[File:1Incision_manager.png|32px|link=|Incision Management System]] '''OR''' Open the incision. ([[File:1Scalpel.png|32px|link=|Scalpel]]->[[File:1Hemostat.png|32px|link=|Hemostat]]->[[File:1Retractor.png|32px|link=|Retractor]])
*Fish out the foreign objects until they are all removed. ([[File:1Hemostat.png|32px|link=|Hemostat]])
*Close the incision ([[File:1Cautery.png|32px|link=|Cautery]])
|-
|{{anchor|Sealing a Stump}}[[#Sealing a Stump|Sealing a Stump]] (Severed Arms and Legs)
|Sealing a stump where the patient's arm or leg should have been.
**Seal the stump. ([[File:1Scalpel.png|32px|link=|Scalpel]]->[[File:Fixovein.png|32px|link=|Fix-ovein]] ->[[File:Surgical Line.png|32px|link=|Surgical Line]])
|-
|{{anchor|Autopsy}}[[#Autopsy|Autopsy]] (Only on Permanently Dead)
|Helps find out how the person died. Displays wounds, possible causes, and detected chemicals in the body.
*'''This surgery is of minimal priority and should only be done if you have literally nothing better to do. This is a combat operation, not a funeral parlor.'''
*Aim for the affected area on the deceased using the Hud-target
*Cut the skin open ([[File:1Scalpel.png|32px|link=|Scalpel]]) (the chest may require two cuts).
*Use the autopsy scanner to scan the area. ([[File: Autopsy_scanner.png|32px]])
*Repeat scalpel and scan procedure for all affected areas. ([[File:1Scalpel.png|32px|link=|Scalpel]]->[[File: Autopsy_scanner.png|32px]])
*Right click the autopsy scanner to print out autopsy data. ([[File: Autopsy_scanner.png|32px]])
*Close the incision
|-
([[File:1Cautery.png|32px|link=|Cautery]]) (optional)
|{{anchor|Internal Bleeding Surgery}}[[#Internal Bleeding Surgery|Internal Bleeding Surgery]] (Everywhere except mouth/eyes.)
|This surgery mends the torn/ripped arteries and veins within the body to stop internal bleeding.
*Incision Management System. [[File:1Incision_manager.png|32px|link=|Incision Management System]] '''OR''' Open the incision. ([[File:1Scalpel.png|32px|link=|Scalpel]]->[[File:1Hemostat.png|32px|link=|Hemostat]]->[[File:1Retractor.png|32px|link=|Retractor]])
*Mend the artery. ([[File:Fixovein.png|32px|link=|Fix-o-Vein]])
*Close the incision. ([[File:1Cautery.png|32px|link=|Cautery]])
|-
|}

==== Level 2 Surgeries ====

{| class="wikitable"
!Surgery:
!Description:

|-
|{{anchor|Alien Embryo Removal}}[[#Alien Embryo Removal|Alien Embryo Removal]]
|Removal of an alien embryo from the body.
*'''This must be performed on an operating table'''.
*'''Alien embryos will always be in the chest behind the ribcage. Time is of the essence when removing them, and you must complete this surgery as quickly as possible; your patient will die instantly when it finishes gestating, resulting in the birth of an alien larva. Make haste in removing any embryos.
*Incision Management System. [[File:1Incision_manager.png|32px|link=|Incision Management System]] '''OR''' Open the incision. ([[File:1Scalpel.png|32px|link=|Scalpel]]->[[File:1Hemostat.png|32px|link=|Hemostat]]->[[File:1Retractor.png|32px|link=|Retractor]])
*Open the skull or ribcage if necessary. ([[File:1Saw.png|32px|link=|Bone Saw]]->[[File:1Retractor.png|32px|link=|Retractor]])
*Cut away the larva's pseudoroots.([[File:The_PICT System.png|32px|link=|PICT System]]) '''OR''' use ([[File:1Scalpel.png|32px|link=|Scalpel]]) (very much not recommended, as it deals burn damage to yourself and the patient).
*Pull out the alien embryo. ([[File:1Hemostat.png|32px|link=|Hemostat]]) '''OR''' use your hands (not recommended).
*Close the ribcage.([[File:1Retractor.png|32px|link=|Retractor]]->[[File:1Bone-Gel.png|32px|link|Bone Gel]]).
*Close the incision ([[File:1Cautery.png|32px|link=|Cautery]])

|-
|{{anchor|Bone Repair Surgery}}[[#Bone Repair Surgery|Bone Repair Surgery]] (Everywhere except mouth/eyes.)
|This surgery is used for mending broken bones and fractures.
*'''Note that a repaired bone will rebreak if your patient has more than 50 brute damage.'''
*Incision Management System. [[File:1Incision_manager.png|32px|link=|Incision Management System]] '''OR''' Open the incision. ([[File:1Scalpel.png|32px|link=|Scalpel]]->[[File:1Hemostat.png|32px|link=|Hemostat]]->[[File:1Retractor.png|32px|link=|Retractor]])
*Repair the bone. ([[File:1Bone-Gel.png|32px|link=|Bone Gel]]->[[File:1Bone Setter.png|32px|link=|Bone Setter]]) (Use the Health Analyzer to double check)
*Close the incision. ([[File:1Cautery.png|32px|link=|Cautery]])
|-
|{{anchor|Internal Organs Surgery}}[[#Internal Organs Surgery|Internal Organs Surgery]] (Groin, Chest.)
|Mending broken internal organs such as the heart or appendix. Note that this surgery excludes the eyes and brain as they have their own surgeries respectively.
*'''Peridaxon does not heal organ damage. This is the only way to heal organs in the chest and groin.'''
*Incision Management System. [[File:1Incision_manager.png|32px|link=|Incision Management System]] '''OR''' Open the incision. ([[File:1Scalpel.png|32px|link=|Scalpel]]->[[File:1Hemostat.png|32px|link=|Hemostat]]->[[File:1Retractor.png|32px|link=|Retractor]])
*Open the ribcage if necessary. ([[File:1Saw.png|32px|link=|Bone Saw]]->[[File:1Retractor.png|32px|link=|Retractor]])
*Repair the biological organ with a Trauma Kit, or the robotic organ with Nanopaste. It loops fixing each damaged organ until none remain.([[File:Advtraumakit.png|32px|link=|Advanced Trauma Kit]]/[[File:1Nanopaste.png|32px|link=|Nanopaste]])
*Close the ribcage if necessary. ([[File:1Retractor.png|32px|link=|Retractor]]->[[File:1Bone-Gel.png|32px|link|Bone Gel]])
*Close the incision. ([[File:1Cautery.png|32px|link=|Cautery]])
|-
|{{anchor|Monkey Cube Removal}}[[#Monkey Cube Removal|Monkey Cube Removal]] (Chest.)
|Removing a monkey cube post-ingestion. This surgery is one of the few that require a surgical drill.
*'''The embedded monkey will cause continual organ damage and may even result in the host heartbreaking. Time is of the essence.'''
*Incision Management System. [[File:1Incision_manager.png|32px|link=|Incision Management System]] '''OR''' Open the incision. ([[File:1Scalpel.png|32px|link=|Scalpel]]->[[File:1Hemostat.png|32px|link=|Hemostat]]->[[File:1Retractor.png|32px|link=|Retractor]])
*Open the ribcage. ([[File:1Saw.png|32px|link=|Bone Saw]]->[[File:1Retractor.png|32px|link=|Retractor]])
*Extract the malformed monkey with a hemostat. ([[File:Hemostat.png|32px|link=|Hemostat]]). If this doesn't work, continue with the other steps.
*Drill open the thoracic cavity wall. ([[File:Surgical Drill.png|32px|link=|Surgical Drill]])
*Extract the malformed monkey with a hemostat. ([[File:Hemostat.png|32px|link=|Hemostat]])
*Close the hole with a cautery. ([[File:1Cautery.png|32px|link=|Cautery]])
*Check for organ damage by using an advanced trauma kit or nanopaste if the organ is robotic.([[File:Advtraumakit.png|32px|link=|Advanced Trauma Kit]]/[[File:1Nanopaste.png|32px|link=|Nanopaste]])
*Close the ribcage. ([[File:1Retractor.png|32px|link=|Retractor]]->[[File:1Bone-Gel.png|32px|link|Bone Gel]])
*Close the incision. ([[File:1Cautery.png|32px|link=|Cautery]])
|-
|{{anchor|Eye Surgery}}[[#Eye Surgery|Eye Surgery]] (Eyes.)
|Mending the eyes to cure blindness and eye damage.
*'''Using imidazoline is usually faster than this surgery.'''
* Mend the eyes. ([[File:1Scalpel.png|32px|link=|Scalpel]]->[[File:1Retractor.png|32px|link=|Retractor]]->[[File:1Hemostat.png|32px|link=|Hemostat]]->[[File:1Cautery.png|32px|link=|Cautery]]).
|-
|{{anchor|Brain Damage Surgery}}[[#Brain Damage Surgery|Brain Damage Surgery]] (Head.)
|Fixing up the brain.
*'''Using alkysine is usually faster than this surgery.'''
*Incision Management System. [[File:1Incision_manager.png|32px|link=|Incision Management System]] '''OR''' Open the incision. ([[File:1Scalpel.png|32px|link=|Scalpel]]->[[File:1Hemostat.png|32px|link=|Hemostat]]->[[File:1Retractor.png|32px|link=|Retractor]])
*Open the skull.([[File:1Saw.png|32px|link=|Bone Saw]]->[[File:1Retractor.png|32px|link=|Retractor]])
*Repair severe brain damage, if any. ([[File:Fixovein.png|32px|link=|Fix-O-Vein]])
*Extract embedded bone chips until they are all removed. ([[File:1Hemostat.png|32px|link=|Hemostat]]) (Use Health Analyzer to double check)
*Close the skull. ([[File:1Retractor.png|32px|link=|Retractor]]->[[File:1Bone-Gel.png|32px|link|Bone Gel]])
*Close the incision. ([[File:1Cautery.png|32px|link=|Cautery]])
|-

|{{anchor|Facial Reconstruction Surgery}}[[#Facial Reconstruction Surgery|Facial Reconstruction Surgery]] (Mouth.)
|This surgery fixes facial deformities caused by severe damage to the head. I.E. "Unknown as (name)" when speaking.
*'''This surgery is of minimal priority and should only be done if you have literally nothing better to do. This is a combat operation, cosmetic surgery can wait.'''
*Fix the facial deformities. ([[File:1Scalpel.png|32px|link=|Scalpel]]->[[File:1Hemostat.png|32px|link=|Hemostat]]->[[File:1Retractor.png|32px|link=|Retractor]])
*Close the incision. ([[File:1Cautery.png|32px|link=|Cautery]])
|-
|{{anchor|Amputation}}[[#Amputation|Amputation]] (Limbs: Legs, Arms, Hands, Feet.)
|Removal of a limb.
*Incision Management System. [[File:1Incision_manager.png|32px|link=|Incision Management System]] '''OR''' Open the incision. ([[File:1Scalpel.png|32px|link=|Scalpel]]->[[File:1Hemostat.png|32px|link=|Hemostat]]->[[File:1Retractor.png|32px|link=|Retractor]])

* Use the Incision Management System to sever the muscles. [[File:1Incision_manager.png|32px|link=|Incision Management System]] '''OR''' Sever the muscles using the scalpel. ([[File:1Scalpel.png|32px|link=|Scalpel]])

* (Optional) Cancel the amputation with Fixoven ([[File:Fixovein.png]]) or a surgical line ([[File:Surgical Line.png]])

* Saw through the limb. ([[File:1Saw.png|32px|link=|Bone Saw]])

|-
|{{anchor|Limb Replacement Surgery}}[[#Limb Replacement Surgery|Limb Replacement Surgery]] (Limbs: Legs, Arms, Hands, Feet.)
|The replacement of missing limbs with robotic ones. Robot arms and legs are used to replace hands and feet; there is no need to further amputate if that's all the patient has lost.

If they've lost an organic Limb.
*Seal the stump. ([[File:1Scalpel.png|32px|link=|Scalpel]]->[[File:Fixovein.png|32px|link=|Fix-o-Vein]] -> [[File:Surgical Line.png|32px|link=|Surgical Line]]) (Fix-o-vein and surgical line are substitutes for each other)

If they've lost a robotic limb
*Saw off the remaining clamps holding the broken prosthetic to the body. ([[File:1Saw.png|32px|link=|Bone Saw]])
*Use your hand to take broken prosthetic out

*Attach the robotic limb. (Robotic Limb)
*Tighten the new robotic limb. ([[File:1Hemostat.png|32px|link=|Hemostat]]) '''OR''' Use your hand (Click on them with help intent)
*Calibrate the new robotic limb with your hand. (Click on them with help intent)
*Inform the patient that the robotic limb can be repaired with Blowtorch [[File:Welder.gif|32px]](brute) and Cable coils[[File:CableCoils.png|32px]](burn).
|-
|{{anchor|Synthetic Head Re-Attachment Surgery}}[[#Synthetic Head Re-Attachment Surgery|Synthetic Head Re-Attachment Surgery]] (Head.)
|Re-attaching a decapitated synthetic head.
*Mend the torn silicone tissue. ([[File:1Retractor.png|32px|link=|Retractor]])
*Attach the synthetic head.
*Reconstruct the tissue ([[File:Fixovein.png|32px|link=|Fix-O-Vein]]->[[File:1Cautery.png|32px|link=|Cautery]]).
*Use a Defibrillator [[File:Defibrillator.png|32px|link=|Defibrillator]] on the synthetic.
<small>'''Note: There isn't a timer on defibbing a synthetic.'''</small>


|}

== The Autodoc System ==

The Autodoc system is located in the middle of the treatment center and is only usable by the medical staff (and Squad Medics during WO). Note that while the autodoc is an extremely useful machine in medical, it cannot conduct larva removal surgery. The autodoc used to be able to fix bone damage and organ damage, but this has been removed.
{|border="1"
|+[[File:AutoDoc.png|32px]] '''Operating Mode:'''
|-
|'''Manual:'''
|Manual mode will fix everything of the selected surgery type, but autodoc can no longer fix broken bones or organ damage.

{| border="1" class="mw-collapsible mw-collapsed"
|+ style="text-align:left;"|'''Manual Surgery List:'''
|[[File:Autodoc_manual_list.png]]
|}
'''Trauma Surgeries'''
* '''Shrapnel Removal Surgery:''' Removes all instances of shrapnel from the patient.

'''Hematology Treatments'''
* '''Blood Transfer:''' Transfers blood into the patient. The autodoc has an internal reservoir of O- blood that it refills as needed.
* '''Dialysis:''' Purges chemicals from the patient's blood stream; use with toxin damage chelation to treat poisoning and overdoses.
* '''Toxin Damage Chelation (Kelation):''' Removes toxin damage.

'''Special Surgeries'''
* '''Close Open Incision:''' Closes all open surgical incisions on the patient.
* '''Facial Surgery:''' Treats and repairs facial deformities (typically from physical damage) so the patient can be clearly identified and doesn't look like an unga.
* '''Limb Replacement Surgery:''' Replaces any missing limbs the patient has with robotic prosthetics.
|}

== Combining Surgeries ==

Very often people will come in with multiple problems at once. For instance, you might have a patient who has a fractured skull, brain damage, and shrapnel in their head. Performing three separate surgeries is very time consuming when other marines may be waiting. It is possible to condense the surgery down to one in such a manner:

* Broken skull, brain damage, and head shrapnel removal surgery
#Use the Incision Management System. [[File:1Incision_manager.png|32px|link=|Incision Management System]] '''OR''' ([[File:1Scalpel.png|link=|Scalpel]]->[[File:1Hemostat.png|link=|Hemostat]]->[[File:1Retractor.png|link=|Retractor]]) to make an incision.
# [[File:1Saw.png|link=|Bone Saw]] Cut through the skull
# [[File:1Retractor.png|link=|Retractor]] Open up the skull
# [[File:1Hemostat.png|link=|Hemostat]] Here it gets a bit tricky, use a hemostat repeatedly to pull out bone chips and shrapnel until you get a message that nothing more can be found in the brain. Both types of removal can take several rounds or attempts.
# [[File:Fixovein.png|link=|Fix-O-Vein]] [[File:Advtraumakit.png|link=|Advanced Trauma Kit]] Use the FixOVein and Trauma Kit to repair hematomas and damage to the brain and eyes if necessary
# Use the Health Analyzer to check that the patient does not have brain damage! If the patient still has brain damage go back and use the hemostat and FixOVein more until the Analyzer shows no brain damage.
# [[File:1Retractor.png|link=|Retractor]] Close the skull back up
# [[File:1Bone-Gel.png|link=|Bone Gel]] Use bone gel on the damaged bones in the skull
# [[File:1Bone Setter.png|link=|Bone Setter]] Piece together the broken or fractured skull
# [[File:1Bone-Gel.png|link=|Bone Gel]] Add bone gel once more
# [[File:1Cautery.png|link=|Cautery]] Seal up the incision
# Use the Health Analyzer again to see if the patient needs antibiotics or anti-toxins and administer them as needed

What about an infected marine with a broken chest, internal bleeding, and a ruptured lung? Here you'll want to use medication from the vendors in medbay in order to tackle the problems at hand.

* Alien embryo removal, ruptured lung, and broken chest surgery (with a side of internal bleeding)
# First use one Dexalin Plus injector to halt suffocation damage from the ruptured lung. While you can stop internal bleeding surgically, Keep a couple of Dex+ injector on hand to keep the patient from dying from the ruptured lung.
# [[File:1Scalpel.png|link=|Scalpel]] Make an incision quickly
# [[File:1Retractor.png|link=|Retractor]] '''Ignore bleeders''' and rearrange organs. Removing the larva ASAP is the top priority right now
# [[File:1Saw.png|link=|Bone Saw]] Cut open the rib cage
# [[File:1Retractor.png|link=|Retractor]] Separate the rib cage
# [[File:The_PICT_System.png|link=|PICT System]] Begin cutting out the alien embryo
# [[File:1Hemostat.png|link=|Hemostat]] Begin pulling out the alien embryo
# [[File:Advtraumakit.png|link=|Advanced Trauma Kit]] Repair the ruptured lungs and any other damaged organs, note that a mechanical heart requires [[File:1Nanopaste.png|link=|Nanopaste]] to fix
# [[File:1Hemostat.png|link=|Hemostat]] ''Now'' stem the bleeders with the hemostat
# [[File:1Retractor.png|link=|Retractor]] Close up the rib cage
# [[File:1Bone-Gel.png|link=|Bone Gel]] One application of bone gel for the cut rib cage. Cut rib cages and skulls require one application of bone gel after they've been pushed back together.
# [[File:1Bone Setter.png|link=|Bone Setter]] Set the broken bones in the chest
# [[File:1Bone-Gel.png|link=|Bone Gel]] An application for the set bones. In general remember that fixing a broken bone requires two application of bone gel before the setting it.
# [[File:1Cautery.png|link=|Cautery]] Cauterize the incision, your patient should be recovering nicely now
# Again, use the Health Analyzer to double-check your work and to dispense dylovene as needed

== Tips ==
* Patients can often tell you where they need surgery if an advance scanner is not available.
* The hemostat step can be saved for later in the surgery or skipped entirely at the cost of your patient losing blood volume.
* Be sure to stand in a spot where you won't be pushed around. Any movement will violently fail the surgery step you are currently performing. It is recommended for field surgeons to bring a folding chair for this exact reason.
* The most common type of surgery that a person would need is [[#Bone Repair Surgery|Bone Repair Surgery]] and [[#Internal Organs Surgery|Internal Organs Surgery]]. Be sure to be familiar with the steps. (Using Bone Gel twice is a good habit while fixing Fracs)
* Note that only the [[#Sealing a Stump|Sealing a Stump]] surgery and [[#Alien Embryo Removal|Alien Embryo Removal]] surgery require a high level of anesthetic/painkilling, like what [[#Oxycodone|Oxycodone]] ( [[#PNK|PNK]] 8) or the surgical table provides when hooked up to the patient (provided they have functional lungs).
* [[#Tramadol|Tramadol]] has enough painkilling ( [[#PNK|PNK]] 5) to perform all other surgeries besides [[#Sealing a Stump|Sealing a Stump]] surgery and [[#Alien Embryo Removal|Alien Embryo Removal]]. Tramadol also lasts longer than [[#Oxycodone|Oxycodone]], leading to less time wasted injecting and more time for performing surgery. Ideal for several broken bone surgeries in a row.
* Be sure to check if any [[#Tramadol|Tramadol]] is already in the system when performing the initial scan, as it is often used as a painkiller.

* If you see a broken red heart next to the patient, that means they have heartbreak. The broken heart indicates that the patient's heart has suffered too much trauma for revival attempts. When scanned the message will say: "Patient's general condition does not allow reviving." To fix this, a doctor (or person able to do surgery level 2 or higher) must repair their heart in time before any further revival attempts are under taken. If a doctor (or someone applicable) is not immediately available, perform CPR on the corpse to extend their defib timer until a doctor can perform surgery to repair the heart.
* Shrapnel is never good as it gives organ damage when received, and deals brute damage (which can also cause further organ damage) when moving with it still inside the body. The most common way to remove shrapnel is to way remove with a knife or other sufficiently sharp object. To do this, activate/click yourself/patient on help intent with knife in hand. Yanking out the object is another option (only if object is externally embedded). To do this, right click the person with shrapnel and click '''Yank out object'''. The last option is surgery (only if object is deeply embedded or small to remove).
* Refer to [https://cm-ss13.com/wiki/Guide_to_Medicine| Guide to Medicine], [https://cm-ss13.com/wiki/Chemistry| Chemistry], or the [https://cm-ss13.com/wiki/Researcher| Researcher] page for further information.