Rules and SS13 for Experienced Programmers: Difference between pages

From Chompstation Wiki
(Difference between pages)
Jump to navigation Jump to search
imported>Nadyr
(Complete rules rewrite)
 
imported>Nadyr
(Page restored.)
 
Line 1: Line 1:
{{GetStartedHeader}}
{{BayPage}}
{{hatnote|This article was gratefully copied from the corresponding page on the [http://tgstation13.org/wiki/SS13_for_experienced_programmers /tg/station13 wiki].}}
Other related guides: [[Basics of Coding in BYOND]] and the [[Guide to Mapping]]


'''Always refer to the [https://forums.chompstation13.net/showthread.php?tid=2&pid=2#pid2 forum page] for up-to-date rules. This page may be outdated.'''
So you know how to write programs in other languages and would like a quick guide on how to understand and code for SS13? Good, this is the guide for you. It likely doesn't contain everything that you need to know but it's a start.


== Foreword ==
== Syntax ==
CHOMPstation13 is a vore-based, roleplaying-focused Space Station 13 furry server. As a community, we strive to provide an enjoyable adult roleplaying environment with gameplay to offer immersion and provide game content when members feel like doing something other than roleplay. Since we allow the use of game mechanics in many situations despite being roleplay-focused, we consider ourselves MRP (medium roleplaying).


As a staff team, we prioritize vore first, roleplaying second, and gameplay third. Our enforcement of rules, community focus, and development of the game will typically follow this priority. As a player, if you treat your fellow players with kindness and respect, you will generally fare well. Our community comes here to relax, have fun, and take a break from the stresses of offline life.
*Semicolons at the end are not mandatory,
*Loop, proc, object, variable etc. spans are determined by indentations (similar to Python, see examples below)
  /obj
    var
      i1
      i2
      i3
is the same as (Strongly recommended you use this layout to make searching for variable and proc definitions easier.)
  /obj
    var/i1
    var/i2
    var/i3
which is inturn the same as
  /obj/var/i1
  /obj/var/i2
  /obj/var/i3
*This guide uses the word 'object' for any defined type (see [[#Variable types|Variable types]]) and the word 'obj' for derivatives of atom/obj, which are all objects which can be placed on the map.
*This guide uses the word 'AI controlled' for behavior to do with an [[AI]] player controlling an item. The term 'Game controlled' is used when refering to behavior which the script itself determins (Usually called AI controlled creatures or NPCs)
*All things are inherited from parent objects. If a variable is defined in /obj/item, it doesn't need to be (actually can't be) redefined in /obj/item/weapon.


Please note that we typically host at least one staff-led event every week which may present a different game environment than standard rounds. Many events strive to tell a story and further flesh out CHOMPstation’s roleplaying history, but may be much more gameplay-focused than typical rounds. Rules regarding gameplay and roleplaying tend to be laxer during events, particularly as it can be easy to get carried away during chaos.
=== [http://www.byond.com/members/?command=reference&path=var Variables] ===
Variables are very general, Byond makes no difference in the declaration of strings, integers, etc. (Similar to PHP)


Lastly, when in doubt, send an admin help. While each rule comes with clarifying subsections, it is not possible to cover every potential situation in a short document. If you have any questions or confusion regarding the rules, message a moderator, administrator,  or head administrator. Other forms of staff are not permitted or trained to moderate.
==== [http://www.byond.com/members/?command=reference&path=var Predefined variables] ====
There is a lot of predefined variables for objects in BYOND, but the most important are:
*'''[http://www.byond.com/members/?command=reference&path=proc%2Fvar%2Fsrc src]''' - a variable equal to the object containing the proc or verb. It is defined to have the same type as that object. (Similar to "this" in Java or C++)
*'''[http://www.byond.com/members/?command=reference&path=proc%2Fvar%2Fusr usr]''' - a mob variable (var/mob/usr) containing the mob of the player who executed the current verb, or whose action ultimately called the current proc. '''A good rule of thumb is to never put usr in a proc.''' If src would not be the correct choice, it is better to send another argument to your proc with the information it needs.
*'''[http://www.byond.com/members/?command=reference&path=proc%2Fvar%2Fargs args]''' - a list of the arguments passed to the proc or verb.
*'''[http://www.byond.com/members/?command=reference&path=datum%2Fvar%2Fvars vars]''' - a list of object variables. If the variable name is used as an index into the list, the value of that variable is accessed.


Unfamiliar with some of our terminology? We’ve included a glossary at the end of this document.
For more SS13 specific variables see [[#SS13 common variable meanings|SS13 common variable meanings]]


==== Variable definition ====


== Rules Summary ==
=====Basic definitions=====
The following is an abbreviated summary of the rules for quick reference. Each rule is further explained and detailed in the “Rules” section should you need more clarification. We recommend reading the full rules at least once should you participate in our community long-term or desire a whitelist.
  var/j
  var/i = 4
  var/a, b, c


#You must be 18 years or older to play here, no exceptions.
=====Complex definitions=====
#Be respectful toward other players in OOC (including Discord).
The general syntax is [http://www.byond.com/members/?command=reference&path=var var/type/variable_name = value]
#OOC roleplaying preferences must be respected.
#Keep IC and OOC separate.
#Do not powergame or abuse metaknowledge.
#Do not self-antag.
#Do not discuss on-going rounds in Discord.
#Do not go out of your way to disrupt ERP.
#Dormitories are OOC protected for roleplay, even during events.
#Do not backseat moderate.
#Play a reasonably sane and mature character and stay in character.
#The use of racial slurs and/or derogatory/bigoted language toward real life social groups is prohibited
#You are expected to forget the events leading to death.
#Do not inconvenience AFK/disconnected players.
#Suicide is prohibited.
#Roleplay when feasible.
#Do not abuse global OOC.
#Do not disconnect if contacted by the moderation team.
#You are expected to fulfill the basic responsibilities of the job you sign up for.*
#Roles with AI laws must follow said laws.
#The intent of the rules is more important than the letter.
#Listen to the moderation team.


== Rules ==
Examples:
  var/obj/item/I = new/obj/item
  [http://www.byond.com/members/?command=reference&path=operator%2F%40dt%3B I.name] = "Some item"


#You must be 18 years or older to play here, no exceptions. All characters must be 18 or older.
Datum definition and declaration of a variable of that datum type:
##Suspicion of being underage will result in a ban unless you can provide a photo ID proving you are of age. Immature behavior may be taken as evidence of being underage.
  datum/test_datum
##Knowingly remaining silent about an underage user is grounds for a ban.
    var/test_variable = 0 //declaration of the test_variable var
#Be respectful toward other players in OOC (including Discord).
   
##Targeted harassment, conspiracies to drive off/get another player in trouble, and giving out player usernames/ckeys without permission are prohibited.
    proc/set_as(var/i) //proc definition within the test_datum datum
##This rule does not extend to previous drama in other communities.
      test_variable = i //set the test_variable var to the value in the argument
##Reasonable IC drama can be permitted, if kept in moderation. The best rule of thumb is whether or not everybody involved is enjoying the interaction. If you feel unsure, use LOOC.
 
##Letting IC drama bleed into OOC or treating a player’s characters poorly for OOC reasons is prohibited.
  var/datum/test_datum/TD = new/datum/test_datum //TD will now be a reference to a datum of type test_datum
##Pervasive, round-to-round IC drama may violate this rule.
  TD.test_variable = 4  //Byond doesn't know of private variables, so you can set any variables like this
##Politely ignoring somebody you do not want to interact with is permitted.
  [http://www.byond.com/members/?command=reference&path=world world] [http://www.byond.com/members/?command=reference&path=operator%2F%26lt%3B%26lt%3B <<] TD.test_variable //will output 4 to all connected users
##Publicly complaining about other players in Discord is prohibited, even without stating the player’s name. Said player will likely see your message and know exactly what you refer to.
  TD.set_as(10) //Will call the set_as proc in the datum with the argument 10
#OOC roleplaying preferences must be respected.
  TD.test_variable //will output 10 to all connected users
##Characters have an examinable section called “OOC Notes” where ERP preferences are listed. You are likewise expected to fill out your own OOC Notes with your do’s and don'ts before playing.
##We strongly recommend including a brief summary of your vore preferences and major likes/dislikes at the top of your OOC Notes. Dense blocks of text and links to ##F-list work best to provide further detail to your interests after you catch another player’s attention.
##OOC Notes do not protect you from most gameplay. For example, your ERP preferences do not protect you from being arrested for committing a crime but do protect you from a security officer trying to turn an arrest into an ERP scene.
##If you are approached with an uncomfortable ERP topic not mentioned in your OOC Notes, you may say no via LOOC (or using ((double brackets)) if the other player has LOOC disabled). Do not use IC for this; it may be misinterpreted due to the popularity of unwilling ERP scenes.
##Do not attempt to coerce another player into a scene or force yourself into ongoing scenes when a participant has stated disinterest in LOOC. Likewise, you are not required to ERP with anybody, even if preferences match.
##Do not kinkshame others. While calm discussions about interests and dislikes are generally okay, passive-aggressive remarks toward others’ preferences are prohibited.
##Keep in mind that this is a vore server. While you are not required to be into vore to play here, you will be routinely exposed to voraphiles, a vore-centric community, vore roleplay, vore gameplay mechanics, vore discussions, vore humor, voraphile-targeted advertisement, vore-focused staff, and more. If vore makes you uncomfortable, you probably should not play here.
##If you have never tried vore roleplay or developed an opinion on it, we recommend trying it out. If that last line makes you uncomfortable, this might not be the community for you.
#Keep IC and OOC separate.
##You are expected to roleplay a character; thus IC (in character) and OOC (out of character) knowledge, interactions, etc. are separate. You knowing how to setup a supermatter engine does not make your medical doctor knowledgeable in engineering. Similarly, you knowing another player does not mean your character(s) knows that player’s character(s).
##While this rule is always applied when relevant to moderation, it is not always followed due the the prevalence of an “I am my character” mindset in furry communities. If you fear an action might upset another player, ask in LOOC. Do not assume.
#Do not powergame or abuse metaknowledge.
##Better known as “playing to win”, Powergaming consists of acquiring items, assets, etc. for the sake of being powerful. Common examples include adding extra access to ID’s without reason, stealing powerful objects from other departments, or doing the job(s) of other departments when said department is available and willing to do the job itself.
##Metaknowledge consists of acting on knowledge which your character would not reasonably know. This may be from outside of the game (such as the code on Github) or inside of the game (such as dying, witnessing a crime as a ghost, then reporting said crime when revived).
##Using third-party programs (Discord, Skype, etc) to coordinate with other players to gain an in-game advantage (metacommunication) is prohibited. Joining with multiple accounts simultaneously is considered metacommunication.
#Do not self-antag.
##Self-antag refers to a wide range of behavior best described as interfering with other players. This can range from stealing from departments or breaking vending machines to going on a murder spree or blowing up a department.
##This rule has the most amount of grey area due to the sheer number of actions which could be considered antagonistic. A good rule of thumb is whether or not an action will seriously hamper the enjoyment of another player. When in doubt, don’t do it.
##Being a nuisance might not be a good idea even if it does not violate this rule. Pranks and mischief are only enjoyable when those involved are having fun. If your behavior consistently upsets other players, you are probably in the wrong.
##Certain event volunteers during certain events are exempt from this rule, instead following guidelines from an Event Manager.
#Do not discuss on-going rounds in Discord.
##This is considered metacommunication and thus a violation of rule 5.
#Do not go out of your way to disrupt ERP.
##As a vore roleplaying server, vore roleplay is our focus. Attempting to enforce standards which make vore more difficult will likely get you ostracized while actively attempting to prevent or disrupt ERP may result in punishment.
#Dormitories are OOC protected for roleplay, even during events.
##Dorms are reserved for private roleplay. You are not permitted to patrol or break into occupied dorms, even as security/medical. You may not sabotage, destroy, or otherwise intentionally make dorms inaccessible.
##Medical is expected to ignore suit sensors located in the dorms.
##Due to the above restrictions, you may not use dorms to hide from security, stash illegal goods, or otherwise use dorms in a way intended to force other players to carry out their job duties (excluding damaging other players in roleplay).
##Dorms are not for going afk or disconnecting. Falling asleep during your roleplay is fine.
##Maintenance, bathrooms, areas outside of station grounds, areas not publicly observable, and public areas with activated privacy features lack special protections but are considered private for roleplaying purposes. You should not expect complete privacy but will not need to move your roleplay elsewhere.
##Public areas are somewhat of a grey area. While extreme kinks are prohibited, roleplay kept to whispers/subtles is usually okay as is public roleplay if nobody expresses discomfort. You should expect no privacy in public areas and should expect to move or transition to whispers/subtles if asked. A good rule of thumb is to avoid large, public ERP posts in crowded areas.
#Do not backseat moderate.
##Accusing other players of rule-breaking, threatening punishment, and/or threatening to call the staff is prohibited. If somebody is breaking the rules, contact the moderation staff. Threatening to contact us tends to start/worsen drama and may get you in trouble.
##Observing the round solely to search for rule-breaking is prohibited. Many behaviors may seem questionable without context and many rules deliberately include grey area. If everybody involved is enjoying themselves, it is probably not a rule break.
#Play a reasonably sane and mature character and stay in character.
##Your character should have a reasonable set of strengths and weaknesses. Knowing too much or possessing too many skills may violate rule 5.
##Speech should consist of speech, not emoticons or lolspeak.
##This setting contains no magic; your character cannot have any special powers which do not exist in this universe and cannot be replicated with game mechanics. ##Private roleplay in the dorms is the only exception to this.
##OOC Notes and Flavor Text are required. OOC Notes should detail your ERP preferences, Flavor Text should contain at least a basic physical description of your character. Flavor Text should only contain details evident from physically observing your character, not thoughts or backstory.
##Flavor Text may include reference images, though NSFW links should be labelled appropriately. We recommend a short URL such as imgur which allows the game to generate a hyperlink without cutting it off.
##Meme and reference characters are prohibited.
##Whitelisted species are expected to know and follow species lore.
#The use of racial slurs and/or derogatory/bigoted language toward real life social groups is prohibited.
##Words not widely recognized as slurs fall into a grey area. These are evaluated on a case-by-case basis but typically only prohibited when used offensively or directed toward somebody expressing distaste for said word.
##This rule does not extend to in-game only groups.
#You are expected to forget the events leading to death.
##Should you die and be later resleeved, you are expected to forget the events leading to your death. This is particularly important for event rounds with antagonists: if you can identify the antagonist who killed you, the antagonist needs to make sure you cannot be brought back to life for the rest of the round.
##Death during ERP is an exception if all involved players agree to letting you remember. Ask first, do not assume.
##Seeking revenge for an OOCly consented death is heavily frowned on and may violate rules 2, 3, 4, 6, and 8. If a fatal kink makes you want to seek revenge, do not roleplay it.
#Do not inconvenience AFK/disconnected players.
##IC emergencies and events may override this rule.
##Disconnected players may be placed in cryosleep after 30 minutes of inactivity.
##Jail time served while disconnected still counts as jail time served.
##You may not eat disconnected players unless their OOC notes explicitly allow such.
#Suicide is prohibited.
##This is mostly due to suicide being used for attention and/or guilting other playersinto roleplay.
##This only applies to suicide. Space Station 13 is designed to teach you the game by killing you in a wide variety of stupid, often humorous means.
#Roleplay when feasible.
##Keep in mind that player-versus-player combat may violate other rules.
##You are expected not to engage in player-versus-player combat without reasonable provocation. Common examples of provocation include roleplay clearly leading into a fight, harassment after a stated threat, or harmless mechanics building into harmful mechanics.
##Fleeing from security, brandishing a deadly weapon, moving when being aimed at, and attempts to disarm frequently count as reasonable provocation.
##Playing a typically AI-controlled mob and acting like an AI-mob or hanging around a dangerous location may count as provocation. It is frequently not obvious at first glance when a hostile mob is player-controlled.
##This rule is not strictly enforced and is typically applied during player disputes about appropriate/inappropriate use of mechanics.
#Do not abuse global OOC.
##Global OOC is intended for short announcements and simple questions. Drama, lengthy discussions, spam, memes, rants, and generally anything which floods the chatbox is prohibited. We have Discord for this.
##Complaining about misuse of Global OOC in Global OOC is misuse of Global OOC.
#Do not disconnect if contacted by the moderation team.
##Disconnecting when contacted about a rule violation will be regarded as an attempt to avoid punishment. If you must leave, say something first.
##We will be understanding if your internet cuts out at a bad time but you may need to contact us through Discord.
#You are expected to fulfill the basic responsibilities of the job you sign up for.
##Repeatedly failing to do the bare minimum required by your department may result in a job ban. The specifics vary from job to job while Heads of Staff are held to higher standards than other staff.
##Your character must be physically capable of performing the job. For example, most jobs require at least one functioning hand. Security needs to be physically capable of subduing criminals and thus lack easily exploitable traits such as lightweight or dirt weakness.
##You are expected to obey reasonable orders from your Head of Staff (or Central Command, if you are the Colony Director).
##As a Head of Staff, you are expected to give reasonable orders and only when necessary. Micromanaging a department on a quiet round or ordering your staff to drop a roleplay to handle a nonessential chore will quickly earn you the ire of other players and may cost you your whitelist if severe. If an essential duty crops up and your staff are unavailable, you are expected to handle it.
##Heads of Staff are expected to be knowledgeable in their department. A whitelist is not a license to take command of a department you have never played.
##As a Head of Staff, abusing your authority against players you dislike is prohibited and may violate other rules.
##This rule does not apply to failing a job due to not knowing the job. You are expected to make mistakes frequently while learning a new job.
#Roles with AI laws must follow said laws.
##Lawed roles (AI, cyborg, drones) must follow their AI laws, even if the laws are illegal or require disobeying Command staff.
##If you believe a law or order breaks server rules, send an adminhelp.
##This rule is not a license for other players to prevent you from doing your job or bar you from roleplaying. If your orders prevent you from having fun, contact the moderation team for a second opinion.
#The intent of the rules is more important than the letter.
##The rules deliberately contain much grey area as it is not possible to detail every potential situation which does/does not violate the rules. The intent and thus enforcement of the rules is to provide an enjoyable roleplaying environment for a community of voraphiles.
##As such, a rule may not be enforced if everybody involved is enjoying themselves. Similarly, a situation which upsets a large number of players may need admin intervention even if not specifically addressed in the rules.
##If it is not yet clear, attempting to find a technicality in the wording of the rules will be ignored. If your behavior is causing problems for many other players, it must stop.
#Listen to the moderation team.
##As implied by rule 21, the enforcement of the rules is flexible and thus up to interpretation by the moderation team. Our job is to tackle problems not mentioned in the rules and never seen before by anybody on the team: if an admin tells you to do something, do it; if an admin tells you to stop, stop. If you disagree with a ruling, contact the staff member after the situation settles. We frequently need to make quick decisions on limited information and may not be able to fully address your concerns in the heat of the moment.
##If you suspect bias, you may discuss your case with up to three administrators. Pressing the issue further will be considered harassment.


== Roleplaying Resources ==
==== Bitflags ====
New to roleplaying? Want to understand more about what distinguishes roleplay from gameplay? We have included some links to helpful roleplaying guides. You are not required to read any of the following resources. That said, springhole is full of roleplaying and writing tips useful for both newcomers and veterans; these links are just a handful which we find relevant to roleplaying in ss13.
Bitflags are variables which use bits instead of numbers to determine conditions. The bit operators are [http://www.byond.com/members/?command=reference&path=operator%2F%26 &] and [http://www.byond.com/members/?command=reference&path=operator%2F%7C |]. For now, you should know that bitflag operators use the binary value of numbers to determine the result. So [http://www.byond.com/members/?command=reference&path=operator%2F%26 13 & 3] will result in 1. ([http://www.byond.com/members/?command=reference&path=operator%2F%26 1101 & 0011 = 0001]) and [http://www.byond.com/members/?command=reference&path=operator%2F%7C 13 | 3 = 15] ([http://www.byond.com/members/?command=reference&path=operator%2F%7C 1101 | 0011 = 1111]) see [[#If|if]] for uses


https://springhole.net/writing/beginner-tips-for-entering-a-roleplaying-community.htm
==== Variable types ====
[http://www.byond.com/members/?command=reference&path=var reference]


https://springhole.net/writing/common-problems-in-roleplaying-characters.htm
*[http://www.byond.com/members/?command=reference&path=datum datum] - ordinary object type (class in java)
*[http://www.byond.com/members/?command=reference&path=atom atom] - atom derives into obj, turf, mob and area
*[http://www.byond.com/members/?command=reference&path=turf turf] - tiles which make up the floors, walls and space on SS13
*[http://www.byond.com/members/?command=reference&path=area area] - areas are grouped locations. They combine many turfs and it gives some common properties. Power, atmosphere, etc. are determined by areas
*[http://www.byond.com/members/?command=reference&path=mob mob] - an object with life, be it game controlled or player controlled.
*[http://www.byond.com/members/?command=reference&path=obj obj] - objects which can be placed on the map
*[http://www.byond.com/members/?command=reference&path=client client] - a new client object is created for each connected player
*[http://www.byond.com/members/?command=reference&path=list list] - a list of elements. The first element in a list called L is L[1]
*[http://www.byond.com/members/?command=reference&path=world world] - this is a variable where some global variables for the entire world can be set. World's contents var contains all atoms currently in the game world.


https://springhole.net/writing/general-roleplaying-tips-and-advice.htm
==== [http://www.byond.com/members/?command=reference&path=operator%2F%26lt%3B%26lt%3B%2Foutput Outputting messages] ====
The most basic way of outputting messages is with the [http://www.byond.com/members/?command=reference&path=operator%2F%26lt%3B%26lt%3B%2Foutput '<<' output operator].


https://springhole.net/writing/tips-to-avoid-killing-rp-conversations.htm
  [http://www.byond.com/members/?command=reference&path=world world] [http://www.byond.com/members/?command=reference&path=operator%2F%26lt%3B%26lt%3B <<] "Hello World!" //Outputs a message to all clients in the world
  [http://www.byond.com/members/?command=reference&path=proc%2Fvar%2Fusr usr] [http://www.byond.com/members/?command=reference&path=operator%2F%26lt%3B%26lt%3B <<] "Hello usr" //Outputs a message to only the user who is tied to the calling of the proc which contains this.


https://springhole.net/writing/introduction-to-roleplaying.htm
===== Output with variables =====
  var/s1 = "Hello"
  var/s2 = "World"
  var/i = 2011
  [http://www.byond.com/members/?command=reference&path=world world] [http://www.byond.com/members/?command=reference&path=operator%2F%26lt%3B%26lt%3B <<] "[s1] [s2], this guide was written in [i]" //Returns "Hello World, this guide was written in 2011"


https://springhole.net/writing/writing-intimate-scenes.htm
==== Determining variable types in code ====
The [http://www.byond.com/members/?command=reference&path=proc%2Fistype istype()] proc will come in handy


Example
  var/obj/item/weapon/W = new/obj/item/weapon/baton
  if([http://www.byond.com/members/?command=reference&path=proc%2Fistype istype](W,/obj/item/weapon/baton))
    [http://www.byond.com/members/?command=reference&path=world world] << "It's a baton!"


== Glossary ==
The second argument is optional, if it's omitted, the variable will be checked against its declared type, like
'''AFK''': Away from keyboard. Refers to online players not currently interacting with/paying attention to the game.
  var/obj/item/weapon/W = new/obj/item/weapon/baton
  if([http://www.byond.com/members/?command=reference&path=proc%2Fistype istype](W))
    [http://www.byond.com/members/?command=reference&path=world world] << "It's a weapon!"


'''Bellybrig''': Serving a sentence to the brig in a stomach instead of the brig.
Standard code for getting specific arguments from variables which have a type that is a subclass of the type the current proc treats them with (see any attackby() proc for examples). Note that the example below is of a proc which is globaly defined, not tied to the object. It doesn't make much sense to do it like this but it works for the purposes of the example. /obj objects don't have the 'amount' variable, it's defined in /obj/item/stack (as ilustrated by the oversimplified definition of classes below. Also note where var/ is used and where it isn't).
  /obj
    var/name = "Object"
 
  /obj/item
    name = "Item"
 
  /obj/item/stack
    name = "Stack"
    var/amount = 50
 
  proc/get_amount(var/obj/O)
    if([http://www.byond.com/members/?command=reference&path=proc%2Fistype istype](O,/obj/item/stack))
      var/obj/item/stack/S = O
      return [http://www.byond.com/members/?command=reference&path=operator%2F%40dt%3B S.amount]


'''Dogborg''': A type of playable cyborg with the appearance of a dog.  
There is another way of doing this. I'll show you that it exists but it is NOT TO BE USED.
  proc/get_aount(var/obj/S)
    if([http://www.byond.com/members/?command=reference&path=proc%2Fistype istype](O,/obj/item/stack))
      return [http://www.byond.com/members/?command=reference&path=operator%2F%3A O:amount]
The [http://www.byond.com/members/?command=reference&path=operator%2F%3A colon operator] (:) in the example above tells the byond compiler: "I know what I'm doing, so ignore the fact the object doesn't have this variable, I'll make sure it works myself." The problem is that people will revise your code and use it in ways you never planed for. This means something might eventually make the O:amount throw exceptions in the form of runtime errors. Some variables might eventually need to be removed or replaced and this is impossible when they are used with object:variable as the compiler will not throw an error when the variable is removed. The error will only become apparent after the game is ran on the live server which might cause it to crash. So just don't use this method, ever.


'''Drop nom''': A mechanic in which falling onto another player results in one eating the other. Controlled by spontaneous vore preference toggles.
There are some shortcuts to [http://www.byond.com/members/?command=reference&path=proc%2Fistype istype()] proc:<br>
[http://www.byond.com/members/?command=reference&path=proc%2Fisarea isarea(variable)] = istype(variable, /area)<br>
[http://www.byond.com/members/?command=reference&path=proc%2Fisicon isicon(variable)] = istype(variable, /icon)<br>
[http://www.byond.com/members/?command=reference&path=proc%2Fismob ismob(variable)]  = istype(variable, /mob)<br>
[http://www.byond.com/members/?command=reference&path=proc%2Fisobj isobj(variable)]  = istype(variable, /obj)<br>
[http://www.byond.com/members/?command=reference&path=proc%2Fisturf isturf(variable)] = istype(variable, /turf)<br>
[http://www.byond.com/members/?command=reference&path=proc%2Fisloc isloc(variable)]  = ismob(variable) || isobj(variable) || isturf(variable) || isarea(variable)


'''ERP''': Erotic roleplay. Any form of roleplay intended to be erotic, typically vore, sex, or other kinks. This is the main focus of the server.
==== Switching between variable types in code ====


'''Godmodding''': Controlling another player’s character in a roleplay. This typically refers to writing another player’s actions or backstory without permission.  
Byond defined:<br>
[http://www.byond.com/members/?command=reference&path=proc%2Fascii2text ascii2text]<br>
[http://www.byond.com/members/?command=reference&path=proc%2Ffile2text file2text]<br>
[http://www.byond.com/members/?command=reference&path=proc%2Flist2params list2params]<br>
[http://www.byond.com/members/?command=reference&path=proc%2Fnum2text num2text]<br>
[http://www.byond.com/members/?command=reference&path=proc%2Fparams2list params2list]<br>
[http://www.byond.com/members/?command=reference&path=proc%2Ftext2ascii text2ascii]<br>
[http://www.byond.com/members/?command=reference&path=proc%2Ftext2file text2file]<br>
[http://www.byond.com/members/?command=reference&path=proc%2Ftext2num text2num]<br>
[http://www.byond.com/members/?command=reference&path=proc%2Ftext2path text2path]<br>
[http://www.byond.com/members/?command=reference&path=proc%2Ftime2text time2text]<br>


'''Grab & Gulp''': Eating players without roleplay. Frowned on unless explicitly permitted in the prey’s OOC notes.
SS13 Defined:<br>
text2dir(direction)<br>
dir2text(direction)<br>
dd_file2list(file_path, separator)<br>
dd_text2list(text, separator, var/list/withinList)<br>
dd_text2List(text, separator, var/list/withinList)<br>
dd_list2text(var/list/the_list, separator)<br>
angle2dir(var/degree)<br>
angle2text(var/degree)<br>


'''IC''': In character. This is a general term encompassing the game setting, character actions, and pretty much anything observable/knowable from a character’s perspective. Contrasted with OOC.
For more useful procs see<br>
[http://code.google.com/p/tgstation13/source/browse/trunk/code/defines/procs/helpers.dm code/defines/procs/helpers.dm]<br>
[http://code.google.com/p/tgstation13/source/browse/trunk/code/game/objects/items/helper_procs.dm code/game/objects/items/helper_procs.dm]


'''LOOC''': Local out of character. Refers to in-game OOC text generated by the LOOC command, visible only to nearby players/ghosts within view range.
=== [http://www.byond.com/members/?command=reference&path=proc%2Fif If] ===


'''OC''': Original character. Refers to a character created by a player in contrast to a character from a published work. Not to be confused with OOC.
Ifs default to checking for true if not otherwise stated. True is defined for all variable types as empty, 0 or non-existant (null).
  if(condition)
    action_true()
  else
    action_false()


'''OOC''': Out of character. Refers to almost anything outside of the game setting, frequently players themselves or conversations in the community Discord. Also refers to text in ((double brackets)), a common convention for communicating in OOC using commands typically reserved for IC (such as Say, Me, Whisper, or Subtle). May also refer to global OOC, the in-game blue text generated when using the OOC command. Contrasted with IC.
==== Common variable behavior in if statements: ====
{|
!Variable type
!False when
!True when
|-
!String (text / ascii)
|"" or null
|Anything else
|-
!Int / Real
|0 or null
|Anything else
|-
!datum, atom
|null
|Anything else
|}


'''OOC Notes:''' A section of a player’s examination description stating the player’s roleplaying preferences.
==== [http://www.byond.com/members/?command=reference&path=operator Logical operators] ====
Pretty standard:
  [http://www.byond.com/members/?command=reference&path=operator%2F%21 !statement1] //NOT statement1
  [http://www.byond.com/members/?command=reference&path=operator%2F%26%26 (statement1) && (statement2)] //statement1 AND statement2
  [http://www.byond.com/members/?command=reference&path=operator%2F%7C%7C (statement1) || (statement2)] //statement1 OR statement2
  [http://www.byond.com/members/?command=reference&path=operator%2F%3D%3D ==] //equals
  [http://www.byond.com/members/?command=reference&path=operator%2F%21%3D !=] //not equal
  [http://www.byond.com/members/?command=reference&path=operator%2F%26lt%3B <] ([http://www.byond.com/members/?command=reference&path=operator%2F%26lt%3B%3D <=]) //less (or equal)
  [http://www.byond.com/members/?command=reference&path=operator%2F%26gt%3B >] ([http://www.byond.com/members/?command=reference&path=operator%2F%26gt%3B%3D >=]) //more (or equal)
  [http://www.byond.com/members/?command=reference&path=operator%2F%26 &] //bitflag AND operator. 13 & 3 = 1 (1101 & 0011 = 0001)
  [http://www.byond.com/members/?command=reference&path=operator%2F%7C |] //bitflag OR operator. 13 | 3 = 15 (1101 | 0011 = 1111)


'''Me''': An in-game command for describing a character’s actions. Used for any form of roleplaying except exclusively verbal posts.
Byond does not recognize the === (identical) operator. More operators can be found in the left menu on the [http://www.byond.com/members/?command=reference&path=operator reference page]


'''Medbelly''': Using a stomach in heal mode to heal injured crew. Typically used in reference to medical dogborgs. Synonymous with healbelly.
=== [http://www.byond.com/members/?command=reference&path=proc%2Fwhile While] ===
Byond will cancel a loop if it reaches a certain number of iteration and give a runtime error out of fear of infinite loops. Same applies for recursions.
Same as anywhere else
  while(condition)
    action1()


'''Metaknowledge''': Any information a character has no way of realistically knowing. Typically refers to information knowable by a player but not a player’s character.
All loops understand the [http://www.byond.com/members/?command=reference&path=proc%2Fcontinue continue] and [http://www.byond.com/members/?command=reference&path=proc%2Fbreak break] commands


'''Post''': Any written action/dialogue. Typically refers to a player’s turn when roleplaying.
=== For ===
All loops understand the [http://www.byond.com/members/?command=reference&path=proc%2Fcontinue continue] and [http://www.byond.com/members/?command=reference&path=proc%2Fbreak break] commands


'''Powergaming''': A “playing to win” mentality. This refers to a broad range of behaviors typically geared toward scoring a win against another player, such as attempting to outperform everybody else. Powergaming is usually toxic and may violate the rules.  
For combines the for loop and foreach loop:
====  [http://www.byond.com/members/?command=reference&path=proc%2Ffor%2Floop For loop] ====
  for(var/i = 1; i <= 10; i++)
    [http://www.byond.com/members/?command=reference&path=world world] << i //Will write (each in a new line) 1 2 3 4 5 6 7 8 9 10


'''Robust''': A vague ss13 term typically referring to competency with game mechanics, using mechanics instead of roleplay, or engaging in PvP combat. Difficult to define due to lack of a consistent definition.  
==== [http://www.byond.com/members/?command=reference&path=proc%2Ffor%2Flist For each] ====
  for(var/obj/item/weapon/baton/B [http://www.byond.com/members/?command=reference&path=operator%2Fin in] world)  //will iterate through world.contents (which contains all atoms in the world) and only pick those which are of the given type (/obj/item/weapon/baton)
    B.name = "Smelly baton" //Will apply the new name to the baton in the current iteration loop


'''RP''': Roleplay. A broad term referencing a person acting out a role they do not possess or playing a character other than themself. Here, roleplaying typically refers to writing out a character’s speech and actions with other players’ characters and frequently excludes gameplay without writing. Most roleplay here can be categorized as ERP.
=== [http://www.byond.com/members/?command=reference&path=proc%2Fdo Do - While] ===


'''Say''': A command used exclusively for spoken dialogue. Automatically formats posts with quotes and a speech verb.
The Do while operator is not commonly used in SS13 code, Byond does support it tho.


'''Slip vore''': A mechanic in which slipping into another player results in one eating the other. Controlled by spontaneous vore preference toggles.
  var/i = 3
  do
    world << i--
  while(i)


'''SS13''': Space Station 13, the game these rules are about.
All loops understand the [http://www.byond.com/members/?command=reference&path=proc%2Fcontinue continue] and [http://www.byond.com/members/?command=reference&path=proc%2Fbreak break] commands


'''SSD''': Space sleeping disorder. An in-universe explanation for characters passing out whenever their player disconnects.
=== [http://www.byond.com/members/?command=reference&path=datum Defining objects] ===
Doesn't matter if you want a [http://www.byond.com/members/?command=reference&path=datum datum] or [http://www.byond.com/members/?command=reference&path=atom atom], the definition of objects is the same and simple:
  /obj/item/weapon/item1 //will nmake a new object of type obj.
    var/item_property = 5 //Will define a new variable type for all item1 objs
    name = "Testing Item" //The name var is already defined in parent objects so it is not defined here, but only assigned a new valie.
 
  /obj/item/weapon/item1/[http://www.byond.com/members/?command=reference&path=datum%2Fproc%2FNew New()] //Constructor proc
    [[#..()|..()]] //should always be present in New() procs, see [[#..()|..()]] for more information
    item_property = 3 //An action that is performed in the object constructor.


'''Subtles''': A “Me” command displayed only to adjacent players. Subtles are italicized.  
=== [http://www.byond.com/members/?command=reference&path=proc Procs] (Methods, functions, procedures) ===
You're used to the standards of methods, functions and procedures, right? Well procs ignore some aspects of these. They can best be compared to Java methods, as they're tied to specific objects. They cannot be defined as static, private, public, etc. tho. You can write static methods, however the compiler will not restrict you from calling them in a non-static way or environment. Same applies for non-static methods.


'''Televore''': Any vore mechanic involving a prey somehow teleporting into a predator, usually with one of many teleportation devices. Controlled by spontaneous vore preference toggles.
  proc/proc_name(var/argument1, var/argument2)
    [http://www.byond.com/members/?command=reference&path=world world] << "[argument1] [argument2]"


'''TF''': Transformation. Typically refers to a roleplay in which a participant is transformed into something else. May also refer to the transformation belly mode.
The above would declare a global proc. If you wish to tie it to a certain level


'''Vorespawn''': A vore mechanic in which a prey enters the round by spawning into a predator or a predator enters the round by spawning around a prey. Controlled by vore spawn preference toggles.
==== ..() ====
This is the same as super() in Java. It calls the parent object type's proc with the same name and same arguments.


'''Whisper''': A “Say” command fully displayed only to adjacent players. Whispers are italicized.
Example:
  /obj/item
    name = "Item"
 
  /obj/item/New() //New() is the proc that gets called whenever a new object of this type is created. A constructor if you will.
    src.name = "It's an item!"
 
  /obj/item/stack
    name = "Stack"
 
  /obj/item/stack/New()
    src.name = "It's a stack!"
    ..()


If you have the code from the example above and create a new object of type /obj/item/stack, it will first make the item in the game world with the name "Stack", because it's defined to be that by default. Then the New() proc will be called immedietally after. This will change the name to "It's a Stack!" but the call of the parent type's New() proc with the ..() command will then set it to "It's an item!". So in the end, the new object will be called "It's an item!". The ..() command is however very important in many cases as some things are defined only in the common parent's New() procs. In Del(), the proc which gets called prior to an object's deletion, it requires the code to get to the root Del() proc to even delete it. See examples of Del() in the code.


[[Category:Guides]]
== Important procs ==
[[Category:Rules]]
 
=== [http://www.byond.com/members/?command=reference&path=atom%2Fproc%2FNew New()] ===
This proc is called whenever a new instance of the object is created. It can have arguments if needed. It should call ..() where applicable so that parent constructors can be applied.
 
If you wish to create a New() proc for [[#Variable types|atoms]] with custom arguments, ensure the first argument is for the object's location. Example:
  obj/item/weapon/my_item/New(var/location, var/i)
    ..()
    //Whatever else you need to do
 
To make a general object use
  [http://www.byond.com/members/?command=reference&path=proc%2Fnew new] /datum/test_datum
To make an atom (which usually has a locaiton)
  [http://www.byond.com/members/?command=reference&path=proc%2Fnew new] /obj/item/weapon(src.loc)
For the custom example above, the code to create a new such object would be: The 5 is just an example of a value which could be assigned to the var/i in the constructor.
  [http://www.byond.com/members/?command=reference&path=proc%2Fnew new] /obj/item/weapon/my_item(src.loc, 5)
Where src is the proc owner, which contains the line above. src.loc is the locaiton of the src object.
 
=== [http://www.byond.com/members/?command=reference&path=datum%2Fproc%2FDel Del()] ===
This proc gets called before an object's delection. It MUST call ..() at the end as the actual deletion is done in the root Del() proc.
 
An object is deleted by using the del(O) proc with O being the object to be deleted.
 
=== attack_hand(mob/M as mob) ===
Whenever a user (M) clicks on the object with an empty active hand
 
=== attack_paw(mob/M as mob) ===
Whenever a monkey (M) clicks the object with an empty active hand
 
If a custom attack_paw(mob/user) proc is not written for an atom, it defaults to calling attack_hand(user)
 
=== attack_ai(mob/user) ===
Whenever an AI or cyborg clicks the object with an empty active hand
 
If a custom attack_ai(mob/user) proc is not written for an atom, it defaults to calling attack_hand(user)
 
=== attack(mob/M as mob, mob/user as mob) ===
When the object is used to attack mob M by mob user
 
=== attackby(obj/item/W, mob/user) ===
When the object is being attacked by user with W (Example: If you click on wires with wirecutters)
 
=== ex_act(severity) ===
How the item reacts to explosions. Severity can either be 1, 2 or 3 with 1 being the most destructive.
 
=== blob_act() ===
How the item reacts to a blob (magma) attack
 
=== emp_act(severity) ===
How the item reacts to an EMP. Severity can either be 1 or 2 with 1 being the more powerful EMP surge.
 
=== [http://www.byond.com/members/?command=reference&path=datum%2Fproc%2FTopic Topic(href, href_list)] ===
This one's called when you click a link in a pop-up window. Like when you increase the output of [[SMES cells]]. The href_list variable is the important one as it's a parsed version of the arguments you add into a link. To make a link in the pop-up window, add the following line to the text you display (dat in the example):
  <nowiki>dat += </nowiki>[http://www.byond.com/members/?command=reference&path=proc%2Ftext text](<nowiki>"<A href='?src=\ref[src];select=[i]'>[src.name]</a><br>")</nowiki>
Check the code for more examples of this.
 
=== process() ===
This gets called for all objects on every tick. If possible, avoid it as it's processor heavy, but for some things it just can't be avoided.
 
== SS13 common variable meanings ==
 
=== Datum ===
 
Datums have the smallest number of pre-defined variables. These are present in all objects in the game:
  type //The type of an object. If your object is of type /obj/item/weapon/shovel writing the following: new src.type(src.loc) will make another shovel in the same tile.
  parent_type //Parent type of /obj/item/weapon/shovel is /obj/item/weapon... seems streight-foward enough.
  tag //The tag is used to help you identify things when using several instances. It has to be set manually for each instance tho. Lazy coders and mappers resulted in not many tags being used. Instances in the map editor are sorted by tag.
  vars //List of object vars the datum has defined
 
=== Atom ===
 
These variables are shared by all areas, mobs, objs and turfs.
 
  contents //List of contents. Closets store their contents in this var as do all storage items. All the items on a turf are in the turf's contents var.
  density //If density is at 0, you can walk over the object, if it's set to 1, you can't.
  desc //Description. When you right-click and examine an object, this will show under the name.
  dir //Object direction. Sprites have a direction variable which can have 8 'legal' states. [[Understanding SS13 code#Direction (dir) var|More info]]
  gender //not used
  icon //The dmi file where the sprite is saved. Must be written in single quotations (Example: 'items.dmi')
  icon_state //The name of the sprite in the dmi file. If it's not a valid name or is left blank, the sprite without a name in the dmi file will be used. If such a sprite doesn't exist it will default to being blank.
  invisibility //Invisibility is used to determine what you can and what you can't see. Check the code or wait for someone who knows how exactly this works to write it here.
  infra_luminosity //Only mecha use this
  underlays //List of images (see image() proc) which are underlayed under the current sprite
  overlays //List of images (see image() proc) which are overlayed over the current sprite
  loc //Contains a reference to the turf file where the object currently is.
  layer //A numerical variable which determins how objects are layered. Tables with a layer of 2.8 are always under most items which have a layer of 3.0. Layers go up to 20, which is reserved for HUD items.
  luminosity //How much the item will glow. Note that the picking up and dropping of luminous items needs to be specially handled. See flashlight code for an example.
  mouse_over_pointer //not used
  mouse_drag_pointer //(almost) not used
  mouse_drop_pointer //not used
  mouse_drop_zone //not used
  mouse_opacity //Used in a few places. Check the description in the reference page
  name //The name of the object which is displayed when you right click the object and in the bottom left of the screen when you hover your mouse over it.
  opacity //Whether you can see through/past it (glass, floor) when set to 0 or whether you can't (walls, mecha) when set to 1.
  pixel_x //How many pixels in the x direction should the sprite be offset from the starting set. See the APC's New() proc for an example and how fire alarms are defined on the map. pixel_x = -5 will move it 5 pixels to the left and pixel_x = 5 will move it 5 pixels to the right
  pixel_y //Same as pixel_y but in the y direction. Positive values move it to the north, negative to the south.
  pixel_z //Used in isometric maps, so it's not used in SS13
  suffix //Rarely used. See the reference page for more information
  text //How to represent the object on text clients. Not used.
  type //The type of the object
  vars //See [[#Datum|Datum]] above
  verbs //The verbs you can use with the item. Verbs are the options in the right click menu.
  x //X position, read only. Set the loc variable to move it or use the inbulit functions.
  y //Y position, read only.
  z //Z position (Which z-level it's on), read only.
 
=== Area ===
 
  var/requires_power = 1 //Areas which are to work without an APC (Such as centcom areas) should have this at 0. All other areas should have it at 1.
  var/music = null //Music to be played when you enter the area.
  [http://www.byond.com/members/?command=reference&path=atom%2Fvar%2Fluminosity luminosity] = 0 //Areas which should be lit at all times (such as space and centcom) should have this at 1 as well as the sd_lighting var at 0
  var/sd_lighting = 0 //This var determines whether dynamic lighting is to be calculated for the area's tiles. Turn this to off only for areas which have the luminosity var set to 1
 
Most other variables exist only for technical reasons and should not be messed with unless done through existing procs, they are defined in:
  [http://code.google.com/p/tgstation13/source/browse/trunk/code/defines/area/Space%20Station%2013%20areas.dm code/defines/area/Space Station 13 areas.dm]
 
=== Mob ===
 
There is a huge amount of variables for mobs. Take a look at the following files:
  [http://code.google.com/p/tgstation13/source/browse/trunk/code/defines/mob/mob.dm code/defines/mob/mob.dm]
  [http://code.google.com/p/tgstation13/source/browse/trunk/code/defines/mob/dead/observer.dm code/defines/mob/dead/observer.dm]
  [http://code.google.com/p/tgstation13/source/browse/trunk/code/defines/mob/living/living.dm code/defines/mob/living/living.dm]
  [http://code.google.com/p/tgstation13/source/browse/trunk/code/defines/mob/living/carbon/carbon.dm code/defines/mob/living/carbon/carbon.dm]
  [http://code.google.com/p/tgstation13/source/browse/trunk/code/defines/mob/living/carbon/human.dm code/defines/mob/living/carbon/human.dm]
  [http://code.google.com/p/tgstation13/source/browse/trunk/code/defines/mob/living/carbon/monkey.dm code/defines/mob/living/carbon/monkey.dm]
  [http://code.google.com/p/tgstation13/source/browse/trunk/code/defines/mob/living/silicon/silicon.dm code/defines/mob/living/silicon/silicon.dm]
  [http://code.google.com/p/tgstation13/source/browse/trunk/code/defines/mob/living/silicon/ai.dm code/defines/mob/living/silicon/ai.dm]
  [http://code.google.com/p/tgstation13/source/browse/trunk/code/defines/mob/living/silicon/robot.dm code/defines/mob/living/silicon/robot.dm]
There are also additional files for aliens, larva, facehuggers and more there, but the files above will have most of the variables you might need.
 
=== Obj ===
 
  var/m_amt = 0 // How much metal the item has. Used to determine how much metal you get when feeding it into an autolathe and how much it costs to produce it at the lathe
  var/g_amt = 0 // How much glass the item has. Used to determine how much glass you get when feeding it into an autolathe and how much it costs to produce it at the lathe
  var/w_amt = 0 // waster amounts. Not used
  var/origin_tech = null //Used by R&D to determine what research bonuses it grants. See examples in item definitions in code.
  var/reliability = 100 //Used by SOME devices to determine how reliable they are. The number represents the percentual chance for them to work properly.
  var/unacidable = 0 //universal "unacidabliness" var, objects with this set to 1 cannot be destroyed by acids.
  var/throwforce = 0 //The amount of damage applies to a target when they're hit by the item.
 
More variables are defined in:
  [http://code.google.com/p/tgstation13/source/browse/trunk/code/defines/obj.dm code/defines/obj.dm]
 
==== Item ====
 
Items are objs which can be picked up. They're divided into several categories according to their function.
 
/obj/item is defined in the following file:
  [http://code.google.com/p/tgstation13/source/browse/trunk/code/defines/obj.dm code/defines/obj.dm]
 
It adds the following variables (Look at the file for more, but these are the more important ones):
  var/force = null //This determins how much damage the target takes when they're attacked by the item in hand. Small items usually have it at 0, medium ones between 5 and 10, rare and powerful items around 10-15 and two-handed items at 15 and more. Syndicate items have it even higher at 40 and more.
  var/item_state = null //This it the var that determines which sprite will be used for the item from icons/mob/items_lefthand.dmi and items_righthand.dmi.
  var/damtype = "brute" //Determines what damage type the item produces.
  var/health = null //Some items use this to determine when they'll break from use or damage. Not common tho.
  var/hitsound = null //Sound that's played when you hit something with the item. Not commonly used.
  var/w_class = 3.0 //Weight class.
    // w_class = 1 means it's an item that can fit in a pocket (diskette, pen, cigarette packet)
    // w_class = 2 means the item can't fit in pockets but can fit in a box (clipboard, analyzer, cleaner)
    // w_class = 3 means the item can't fit in a box but can fit in backpacks (box, rods, metal)
    // w_class = 4 means the item can't even fit in a backpack (packpack, pickaxe, fireaxe)
    // w_class = 5 is used but not for weight classes.
  var/wielded = 0 //Used for double-handed items which can be carried in one hand but needs to be wielded by two hands before they can be used. This is determined by code when wielding and unwielding. All items should start with this at 0.
  var/twohanded = 0 ///Set this to 1 if your item is two-handed.
  flags = FPRINT | TABLEPASS //Flags
 
==== Machinery ====
 
Defined in:
  [http://code.google.com/p/tgstation13/source/browse/trunk/code/defines/obj/machinery.dm code/defines/obj/machinery.dm]
 
Machinery are objs which cannot be picked up and generally require power to operate. They have the following vars defined for all of them:
  var/use_power = 0 //Determines if and how much power the machine will use each tick.
    //use_power = 0 - no power is used
    //use_power = 1 - idle power is used
    //use_power = 2 - active power is used
  var/idle_power_usage = 0 //How many watts of power the machine will use each tick when use_power is set to 1
  var/active_power_usage = 0 //How many watts of power the machine will use each tick when use_power is set to 2
  var/power_channel = EQUIP //Determines which APC power category the device falls under. EQUIP, ENVIRON or LIGHT
  var/list/component_parts = null //A list of parts needed to construct the machine from a machine frame.
 
=== Turf ===
 
  var/intact = 1 //This determines if the turf will hide pipes, cable and such. Set to 1 to hide and to 0 to not hide them. Only pipes and wire with level set to 1 will be hidden. Set their level var to 2 to keep them from being hidden.
  var/blocks_air = 0 //Determines if the turf prevents air from passing (walls) if set to 1.
Other variables exist but they're tied to atmospherics code which is not to be touched as whenever anything is changed in it it results in a million things breaking.
  [http://code.google.com/p/tgstation13/source/browse/trunk/code/defines/turf.dm code/defines/turf.dm]
 
==== Simulated ====
 
Simulated floors are tiles which simulate air movement and temperature. The station is made entirely from these while centcom is made from unsimulated floors to prevent massive and unneeded lag.
 
  var/wet = 0 //If this it a positive number, it is wet and you'll slip on it if you run.
  var/thermite = 0 //Will be set to 1 when thermite is poured on it.
 
===== Simulated floors =====
 
  var/icon_regular_floor = "floor" //Determines what icon the steel version of the floor should have. Determined at floor creation (New() proc). If the icon_state of the floor at that point is one from the global icons_to_ignore_at_floor_init var, then this variable is assigned the value "floor". The icons_to_ignore_at_floor_init list contains broken, plating, burnt and non-steel icon_states from icons/turf/floors.dmi
  heat_capacity = 10000 //When a fire (hotspot) on the tile exceeds this number, the floor has a chance of melting. The more the number is exceeded, the higher the chance of melting.
  var/broken = 0 //This mostly only determins if you'll get the tile back when you use the crowbar
  var/burnt = 0 //This mostly only determins if you'll get the tile back when you use the crowbar
  var/obj/item/stack/tile/floor_tile = new/obj/item/stack/tile/steel //What floor tile is on the tile
 
Simulated floors are defined in:
  [http://code.google.com/p/tgstation13/source/browse/trunk/code/game/turf.dm code/game/turf.dm]
 
===== Simulated walls =====
 
Doesn't really contain any special new variables.
 
Defined in:
  [http://code.google.com/p/tgstation13/source/browse/trunk/code/defines/turf.dm code/defines/turf.dm]
 
[[Category:Guides]] [[Category:Game Resources]]
{{Contribution guides}}

Latest revision as of 02:34, 11 November 2019

This article or section is from the Baystation 12 wiki.

This article or section is directly taken from the Baystation 12 wiki, and should not be fully relied on for CHOMPstation. You can help by updating it.

Other related guides: Basics of Coding in BYOND and the Guide to Mapping

So you know how to write programs in other languages and would like a quick guide on how to understand and code for SS13? Good, this is the guide for you. It likely doesn't contain everything that you need to know but it's a start.

Syntax

  • Semicolons at the end are not mandatory,
  • Loop, proc, object, variable etc. spans are determined by indentations (similar to Python, see examples below)
 /obj
   var
     i1
     i2
     i3

is the same as (Strongly recommended you use this layout to make searching for variable and proc definitions easier.)

 /obj
   var/i1
   var/i2
   var/i3

which is inturn the same as

 /obj/var/i1
 /obj/var/i2
 /obj/var/i3
  • This guide uses the word 'object' for any defined type (see Variable types) and the word 'obj' for derivatives of atom/obj, which are all objects which can be placed on the map.
  • This guide uses the word 'AI controlled' for behavior to do with an AI player controlling an item. The term 'Game controlled' is used when refering to behavior which the script itself determins (Usually called AI controlled creatures or NPCs)
  • All things are inherited from parent objects. If a variable is defined in /obj/item, it doesn't need to be (actually can't be) redefined in /obj/item/weapon.

Variables

Variables are very general, Byond makes no difference in the declaration of strings, integers, etc. (Similar to PHP)

Predefined variables

There is a lot of predefined variables for objects in BYOND, but the most important are:

  • src - a variable equal to the object containing the proc or verb. It is defined to have the same type as that object. (Similar to "this" in Java or C++)
  • usr - a mob variable (var/mob/usr) containing the mob of the player who executed the current verb, or whose action ultimately called the current proc. A good rule of thumb is to never put usr in a proc. If src would not be the correct choice, it is better to send another argument to your proc with the information it needs.
  • args - a list of the arguments passed to the proc or verb.
  • vars - a list of object variables. If the variable name is used as an index into the list, the value of that variable is accessed.

For more SS13 specific variables see SS13 common variable meanings

Variable definition

Basic definitions
 var/j
 var/i = 4
 var/a, b, c
Complex definitions

The general syntax is var/type/variable_name = value

Examples:

 var/obj/item/I = new/obj/item
 I.name = "Some item"

Datum definition and declaration of a variable of that datum type:

 datum/test_datum
   var/test_variable = 0 //declaration of the test_variable var
   
   proc/set_as(var/i) //proc definition within the test_datum datum
     test_variable = i //set the test_variable var to the value in the argument
 
 var/datum/test_datum/TD = new/datum/test_datum //TD will now be a reference to a datum of type test_datum
 TD.test_variable = 4  //Byond doesn't know of private variables, so you can set any variables like this
 world << TD.test_variable //will output 4 to all connected users
 TD.set_as(10) //Will call the set_as proc in the datum with the argument 10
 TD.test_variable //will output 10 to all connected users

Bitflags

Bitflags are variables which use bits instead of numbers to determine conditions. The bit operators are & and |. For now, you should know that bitflag operators use the binary value of numbers to determine the result. So 13 & 3 will result in 1. (1101 & 0011 = 0001) and 13 | 3 = 15 (1101 | 0011 = 1111) see if for uses

Variable types

reference

  • datum - ordinary object type (class in java)
  • atom - atom derives into obj, turf, mob and area
  • turf - tiles which make up the floors, walls and space on SS13
  • area - areas are grouped locations. They combine many turfs and it gives some common properties. Power, atmosphere, etc. are determined by areas
  • mob - an object with life, be it game controlled or player controlled.
  • obj - objects which can be placed on the map
  • client - a new client object is created for each connected player
  • list - a list of elements. The first element in a list called L is L[1]
  • world - this is a variable where some global variables for the entire world can be set. World's contents var contains all atoms currently in the game world.

Outputting messages

The most basic way of outputting messages is with the '<<' output operator.

 world << "Hello World!" //Outputs a message to all clients in the world
 usr << "Hello usr" //Outputs a message to only the user who is tied to the calling of the proc which contains this.
Output with variables
 var/s1 = "Hello"
 var/s2 = "World"
 var/i = 2011
 world << "[s1] [s2], this guide was written in [i]" //Returns "Hello World, this guide was written in 2011"

Determining variable types in code

The istype() proc will come in handy

Example

 var/obj/item/weapon/W = new/obj/item/weapon/baton
 if(istype(W,/obj/item/weapon/baton))
   world << "It's a baton!"

The second argument is optional, if it's omitted, the variable will be checked against its declared type, like

 var/obj/item/weapon/W = new/obj/item/weapon/baton
 if(istype(W))
   world << "It's a weapon!"

Standard code for getting specific arguments from variables which have a type that is a subclass of the type the current proc treats them with (see any attackby() proc for examples). Note that the example below is of a proc which is globaly defined, not tied to the object. It doesn't make much sense to do it like this but it works for the purposes of the example. /obj objects don't have the 'amount' variable, it's defined in /obj/item/stack (as ilustrated by the oversimplified definition of classes below. Also note where var/ is used and where it isn't).

 /obj
   var/name = "Object"
 
 /obj/item
   name = "Item"
 
 /obj/item/stack
   name = "Stack"
   var/amount = 50
 
 proc/get_amount(var/obj/O)
   if(istype(O,/obj/item/stack))
     var/obj/item/stack/S = O
     return S.amount

There is another way of doing this. I'll show you that it exists but it is NOT TO BE USED.

 proc/get_aount(var/obj/S)
   if(istype(O,/obj/item/stack))
     return O:amount

The colon operator (:) in the example above tells the byond compiler: "I know what I'm doing, so ignore the fact the object doesn't have this variable, I'll make sure it works myself." The problem is that people will revise your code and use it in ways you never planed for. This means something might eventually make the O:amount throw exceptions in the form of runtime errors. Some variables might eventually need to be removed or replaced and this is impossible when they are used with object:variable as the compiler will not throw an error when the variable is removed. The error will only become apparent after the game is ran on the live server which might cause it to crash. So just don't use this method, ever.

There are some shortcuts to istype() proc:
isarea(variable) = istype(variable, /area)
isicon(variable) = istype(variable, /icon)
ismob(variable) = istype(variable, /mob)
isobj(variable) = istype(variable, /obj)
isturf(variable) = istype(variable, /turf)
isloc(variable) = ismob(variable) || isobj(variable) || isturf(variable) || isarea(variable)

Switching between variable types in code

Byond defined:
ascii2text
file2text
list2params
num2text
params2list
text2ascii
text2file
text2num
text2path
time2text

SS13 Defined:
text2dir(direction)
dir2text(direction)
dd_file2list(file_path, separator)
dd_text2list(text, separator, var/list/withinList)
dd_text2List(text, separator, var/list/withinList)
dd_list2text(var/list/the_list, separator)
angle2dir(var/degree)
angle2text(var/degree)

For more useful procs see
code/defines/procs/helpers.dm
code/game/objects/items/helper_procs.dm

If

Ifs default to checking for true if not otherwise stated. True is defined for all variable types as empty, 0 or non-existant (null).

 if(condition)
   action_true()
 else
   action_false()

Common variable behavior in if statements:

Variable type False when True when
String (text / ascii) "" or null Anything else
Int / Real 0 or null Anything else
datum, atom null Anything else

Logical operators

Pretty standard:

 !statement1 //NOT statement1
 (statement1) && (statement2) //statement1 AND statement2
 (statement1) || (statement2) //statement1 OR statement2
 == //equals
 != //not equal
 < (<=) //less (or equal)
 > (>=) //more (or equal)
 & //bitflag AND operator. 13 & 3 = 1 (1101 & 0011 = 0001)
 | //bitflag OR operator. 13 | 3 = 15 (1101 | 0011 = 1111)

Byond does not recognize the === (identical) operator. More operators can be found in the left menu on the reference page

While

Byond will cancel a loop if it reaches a certain number of iteration and give a runtime error out of fear of infinite loops. Same applies for recursions. Same as anywhere else

 while(condition)
   action1()

All loops understand the continue and break commands

For

All loops understand the continue and break commands

For combines the for loop and foreach loop:

For loop

 for(var/i = 1; i <= 10; i++)
   world << i //Will write (each in a new line) 1 2 3 4 5 6 7 8 9 10

For each

 for(var/obj/item/weapon/baton/B in world)  //will iterate through world.contents (which contains all atoms in the world) and only pick those which are of the given type (/obj/item/weapon/baton)
   B.name = "Smelly baton" //Will apply the new name to the baton in the current iteration loop

Do - While

The Do while operator is not commonly used in SS13 code, Byond does support it tho.

 var/i = 3
 do
   world << i--
 while(i)

All loops understand the continue and break commands

Defining objects

Doesn't matter if you want a datum or atom, the definition of objects is the same and simple:

 /obj/item/weapon/item1 //will nmake a new object of type obj.
   var/item_property = 5 //Will define a new variable type for all item1 objs
   name = "Testing Item" //The name var is already defined in parent objects so it is not defined here, but only assigned a new valie.
 
 /obj/item/weapon/item1/New() //Constructor proc
   ..() //should always be present in New() procs, see ..() for more information
   item_property = 3 //An action that is performed in the object constructor.

Procs (Methods, functions, procedures)

You're used to the standards of methods, functions and procedures, right? Well procs ignore some aspects of these. They can best be compared to Java methods, as they're tied to specific objects. They cannot be defined as static, private, public, etc. tho. You can write static methods, however the compiler will not restrict you from calling them in a non-static way or environment. Same applies for non-static methods.

 proc/proc_name(var/argument1, var/argument2)
   world << "[argument1] [argument2]"

The above would declare a global proc. If you wish to tie it to a certain level

..()

This is the same as super() in Java. It calls the parent object type's proc with the same name and same arguments.

Example:

 /obj/item
   name = "Item"
 
 /obj/item/New() //New() is the proc that gets called whenever a new object of this type is created. A constructor if you will.
   src.name = "It's an item!"
 
 /obj/item/stack
   name = "Stack"
 
 /obj/item/stack/New() 
   src.name = "It's a stack!"
   ..()

If you have the code from the example above and create a new object of type /obj/item/stack, it will first make the item in the game world with the name "Stack", because it's defined to be that by default. Then the New() proc will be called immedietally after. This will change the name to "It's a Stack!" but the call of the parent type's New() proc with the ..() command will then set it to "It's an item!". So in the end, the new object will be called "It's an item!". The ..() command is however very important in many cases as some things are defined only in the common parent's New() procs. In Del(), the proc which gets called prior to an object's deletion, it requires the code to get to the root Del() proc to even delete it. See examples of Del() in the code.

Important procs

New()

This proc is called whenever a new instance of the object is created. It can have arguments if needed. It should call ..() where applicable so that parent constructors can be applied.

If you wish to create a New() proc for atoms with custom arguments, ensure the first argument is for the object's location. Example:

 obj/item/weapon/my_item/New(var/location, var/i)
   ..()
   //Whatever else you need to do

To make a general object use

 new /datum/test_datum

To make an atom (which usually has a locaiton)

 new /obj/item/weapon(src.loc)

For the custom example above, the code to create a new such object would be: The 5 is just an example of a value which could be assigned to the var/i in the constructor.

 new /obj/item/weapon/my_item(src.loc, 5)

Where src is the proc owner, which contains the line above. src.loc is the locaiton of the src object.

Del()

This proc gets called before an object's delection. It MUST call ..() at the end as the actual deletion is done in the root Del() proc.

An object is deleted by using the del(O) proc with O being the object to be deleted.

attack_hand(mob/M as mob)

Whenever a user (M) clicks on the object with an empty active hand

attack_paw(mob/M as mob)

Whenever a monkey (M) clicks the object with an empty active hand

If a custom attack_paw(mob/user) proc is not written for an atom, it defaults to calling attack_hand(user)

attack_ai(mob/user)

Whenever an AI or cyborg clicks the object with an empty active hand

If a custom attack_ai(mob/user) proc is not written for an atom, it defaults to calling attack_hand(user)

attack(mob/M as mob, mob/user as mob)

When the object is used to attack mob M by mob user

attackby(obj/item/W, mob/user)

When the object is being attacked by user with W (Example: If you click on wires with wirecutters)

ex_act(severity)

How the item reacts to explosions. Severity can either be 1, 2 or 3 with 1 being the most destructive.

blob_act()

How the item reacts to a blob (magma) attack

emp_act(severity)

How the item reacts to an EMP. Severity can either be 1 or 2 with 1 being the more powerful EMP surge.

Topic(href, href_list)

This one's called when you click a link in a pop-up window. Like when you increase the output of SMES cells. The href_list variable is the important one as it's a parsed version of the arguments you add into a link. To make a link in the pop-up window, add the following line to the text you display (dat in the example):

 dat += text("<A href='?src=\ref[src];select=[i]'>[src.name]</a><br>")

Check the code for more examples of this.

process()

This gets called for all objects on every tick. If possible, avoid it as it's processor heavy, but for some things it just can't be avoided.

SS13 common variable meanings

Datum

Datums have the smallest number of pre-defined variables. These are present in all objects in the game:

 type //The type of an object. If your object is of type /obj/item/weapon/shovel writing the following: new src.type(src.loc) will make another shovel in the same tile.
 parent_type //Parent type of /obj/item/weapon/shovel is /obj/item/weapon... seems streight-foward enough.
 tag //The tag is used to help you identify things when using several instances. It has to be set manually for each instance tho. Lazy coders and mappers resulted in not many tags being used. Instances in the map editor are sorted by tag.
 vars //List of object vars the datum has defined

Atom

These variables are shared by all areas, mobs, objs and turfs.

 contents //List of contents. Closets store their contents in this var as do all storage items. All the items on a turf are in the turf's contents var.
 density //If density is at 0, you can walk over the object, if it's set to 1, you can't.
 desc //Description. When you right-click and examine an object, this will show under the name.
 dir //Object direction. Sprites have a direction variable which can have 8 'legal' states. More info
 gender //not used
 icon //The dmi file where the sprite is saved. Must be written in single quotations (Example: 'items.dmi')
 icon_state //The name of the sprite in the dmi file. If it's not a valid name or is left blank, the sprite without a name in the dmi file will be used. If such a sprite doesn't exist it will default to being blank.
 invisibility //Invisibility is used to determine what you can and what you can't see. Check the code or wait for someone who knows how exactly this works to write it here.
 infra_luminosity //Only mecha use this
 underlays //List of images (see image() proc) which are underlayed under the current sprite
 overlays //List of images (see image() proc) which are overlayed over the current sprite
 loc //Contains a reference to the turf file where the object currently is.
 layer //A numerical variable which determins how objects are layered. Tables with a layer of 2.8 are always under most items which have a layer of 3.0. Layers go up to 20, which is reserved for HUD items.
 luminosity //How much the item will glow. Note that the picking up and dropping of luminous items needs to be specially handled. See flashlight code for an example.
 mouse_over_pointer //not used
 mouse_drag_pointer //(almost) not used
 mouse_drop_pointer //not used
 mouse_drop_zone //not used
 mouse_opacity //Used in a few places. Check the description in the reference page
 name //The name of the object which is displayed when you right click the object and in the bottom left of the screen when you hover your mouse over it.
 opacity //Whether you can see through/past it (glass, floor) when set to 0 or whether you can't (walls, mecha) when set to 1.
 pixel_x //How many pixels in the x direction should the sprite be offset from the starting set. See the APC's New() proc for an example and how fire alarms are defined on the map. pixel_x = -5 will move it 5 pixels to the left and pixel_x = 5 will move it 5 pixels to the right
 pixel_y //Same as pixel_y but in the y direction. Positive values move it to the north, negative to the south.
 pixel_z //Used in isometric maps, so it's not used in SS13
 suffix //Rarely used. See the reference page for more information
 text //How to represent the object on text clients. Not used.
 type //The type of the object
 vars //See Datum above
 verbs //The verbs you can use with the item. Verbs are the options in the right click menu.
 x //X position, read only. Set the loc variable to move it or use the inbulit functions.
 y //Y position, read only. 
 z //Z position (Which z-level it's on), read only.

Area

 var/requires_power = 1 //Areas which are to work without an APC (Such as centcom areas) should have this at 0. All other areas should have it at 1.
 var/music = null //Music to be played when you enter the area.
 luminosity = 0 //Areas which should be lit at all times (such as space and centcom) should have this at 1 as well as the sd_lighting var at 0
 var/sd_lighting = 0 //This var determines whether dynamic lighting is to be calculated for the area's tiles. Turn this to off only for areas which have the luminosity var set to 1

Most other variables exist only for technical reasons and should not be messed with unless done through existing procs, they are defined in:

 code/defines/area/Space Station 13 areas.dm

Mob

There is a huge amount of variables for mobs. Take a look at the following files:

 code/defines/mob/mob.dm
 code/defines/mob/dead/observer.dm
 code/defines/mob/living/living.dm
 code/defines/mob/living/carbon/carbon.dm
 code/defines/mob/living/carbon/human.dm
 code/defines/mob/living/carbon/monkey.dm
 code/defines/mob/living/silicon/silicon.dm
 code/defines/mob/living/silicon/ai.dm
 code/defines/mob/living/silicon/robot.dm

There are also additional files for aliens, larva, facehuggers and more there, but the files above will have most of the variables you might need.

Obj

 var/m_amt = 0	// How much metal the item has. Used to determine how much metal you get when feeding it into an autolathe and how much it costs to produce it at the lathe
 var/g_amt = 0	// How much glass the item has. Used to determine how much glass you get when feeding it into an autolathe and how much it costs to produce it at the lathe
 var/w_amt = 0	// waster amounts. Not used
 var/origin_tech = null //Used by R&D to determine what research bonuses it grants. See examples in item definitions in code.
 var/reliability = 100	//Used by SOME devices to determine how reliable they are. The number represents the percentual chance for them to work properly.
 var/unacidable = 0 //universal "unacidabliness" var, objects with this set to 1 cannot be destroyed by acids.
 var/throwforce = 0 //The amount of damage applies to a target when they're hit by the item.

More variables are defined in:

 code/defines/obj.dm

Item

Items are objs which can be picked up. They're divided into several categories according to their function.

/obj/item is defined in the following file:

 code/defines/obj.dm

It adds the following variables (Look at the file for more, but these are the more important ones):

 var/force = null //This determins how much damage the target takes when they're attacked by the item in hand. Small items usually have it at 0, medium ones between 5 and 10, rare and powerful items around 10-15 and two-handed items at 15 and more. Syndicate items have it even higher at 40 and more.
 var/item_state = null //This it the var that determines which sprite will be used for the item from icons/mob/items_lefthand.dmi and items_righthand.dmi.
 var/damtype = "brute" //Determines what damage type the item produces.
 var/health = null //Some items use this to determine when they'll break from use or damage. Not common tho.
 var/hitsound = null //Sound that's played when you hit something with the item. Not commonly used.
 var/w_class = 3.0 //Weight class.
   // w_class = 1 means it's an item that can fit in a pocket (diskette, pen, cigarette packet)
   // w_class = 2 means the item can't fit in pockets but can fit in a box (clipboard, analyzer, cleaner)
   // w_class = 3 means the item can't fit in a box but can fit in backpacks (box, rods, metal)
   // w_class = 4 means the item can't even fit in a backpack (packpack, pickaxe, fireaxe)
   // w_class = 5 is used but not for weight classes.
 var/wielded = 0 //Used for double-handed items which can be carried in one hand but needs to be wielded by two hands before they can be used. This is determined by code when wielding and unwielding. All items should start with this at 0.
 var/twohanded = 0 ///Set this to 1 if your item is two-handed.
 flags = FPRINT | TABLEPASS //Flags

Machinery

Defined in:

 code/defines/obj/machinery.dm

Machinery are objs which cannot be picked up and generally require power to operate. They have the following vars defined for all of them:

 var/use_power = 0 //Determines if and how much power the machine will use each tick.
   //use_power = 0 - no power is used
   //use_power = 1 - idle power is used
   //use_power = 2 - active power is used
 var/idle_power_usage = 0 //How many watts of power the machine will use each tick when use_power is set to 1
 var/active_power_usage = 0 //How many watts of power the machine will use each tick when use_power is set to 2
 var/power_channel = EQUIP //Determines which APC power category the device falls under. EQUIP, ENVIRON or LIGHT
 var/list/component_parts = null //A list of parts needed to construct the machine from a machine frame.

Turf

 var/intact = 1 //This determines if the turf will hide pipes, cable and such. Set to 1 to hide and to 0 to not hide them. Only pipes and wire with level set to 1 will be hidden. Set their level var to 2 to keep them from being hidden.
 var/blocks_air = 0 //Determines if the turf prevents air from passing (walls) if set to 1.

Other variables exist but they're tied to atmospherics code which is not to be touched as whenever anything is changed in it it results in a million things breaking.

 code/defines/turf.dm

Simulated

Simulated floors are tiles which simulate air movement and temperature. The station is made entirely from these while centcom is made from unsimulated floors to prevent massive and unneeded lag.

 var/wet = 0 //If this it a positive number, it is wet and you'll slip on it if you run.
 var/thermite = 0 //Will be set to 1 when thermite is poured on it.
Simulated floors
 var/icon_regular_floor = "floor" //Determines what icon the steel version of the floor should have. Determined at floor creation (New() proc). If the icon_state of the floor at that point is one from the global icons_to_ignore_at_floor_init var, then this variable is assigned the value "floor". The icons_to_ignore_at_floor_init list contains broken, plating, burnt and non-steel icon_states from icons/turf/floors.dmi
 heat_capacity = 10000 //When a fire (hotspot) on the tile exceeds this number, the floor has a chance of melting. The more the number is exceeded, the higher the chance of melting.
 var/broken = 0 //This mostly only determins if you'll get the tile back when you use the crowbar
 var/burnt = 0 //This mostly only determins if you'll get the tile back when you use the crowbar
 var/obj/item/stack/tile/floor_tile = new/obj/item/stack/tile/steel //What floor tile is on the tile

Simulated floors are defined in:

 code/game/turf.dm
Simulated walls

Doesn't really contain any special new variables.

Defined in:

 code/defines/turf.dm
Contribution Guides & Game Resources
General Guide to Setting Up a Server, Downloading the Source Code, Guide to Contributing to the Game, Game Resources category
Coding Basics of Coding in BYOND, SS13 for Experienced Programmers, [NanoUI]
Mapping Guide to Mapping
Spriting Guide to Spriting
Wiki Guide to Contributing to the Wiki, Style Guide