Pix's Contributionary Corps 101

[Pixeltheaertist]

Sup. I'm making this in hopes of teaching some of y'all how to contribute to ss14 in general. Once you get the hang of it, the simple stuff is quick and easy and lets you add a ton of super fun things that you yourself made to the actual game!

WHY:

• Contributing is fun, once you get the hang of it. You can add your own weapons, objects, clothing, anything!
• It's very helpful, doing little things for the server saves a lot of time on my part
• You can show your friends the big brain stuff you've made and impress them

So without further ado: Welcome to Contributionary Corps 101

HOW TO SET UP:
Generally, you're going to want to follow the setup rules in wizden's website, by saying !howdoicode in any channel on the main SS14 discord. Pretty much, set up a GIT program (i use git bash), set up the required DOTNET and python downloads and then clone the repo to a local folder by opening your preferred git program, clicking on the empty folder and typing

git clone https://github.com/Pixeltheaertist/Trieste-Port-14.git

This will send the repo to a local folder for you to easily edit. Also set up a coding software of some kind (i use Visual Studio Code)

BASIC CODE TYPES:
There are some basic things to know about the code before contributing. It's really simple, so let's go over it.

• .RSI folders
  • All these are folders that contains two main things, the .PNG files that sprites use and the .JSON file that explains to the code
    what those said sprites are, and how they will be used. Think of the .JSON like a translator.
• YAML (.yml) code
  • This is the simplest "code" in the game. The next section will go into it in more detail, but it's pretty much just a stack of
    attributes and components. It simply explains "what is this, what can it do?" All items in the game are .yml files somewhere.
• .CS (C#) files
  • This is the harder stuff, the real big bad code. I don't expect y'all to learn this very fast, hell, i'm still learning it lol. But any files
    labeled .cs are c# files that control systems, components and events in the game's code. Usually the file name will say what it is.

YAML CODE:
YAML (or .yml for file names) is, again, extremely simple. It just describes what an object is, what it's named, what it looks like and what it can do. It uses pre-made components to build unique objects. You can also add new components, but that's C# stuff.

Here's an example of a YAML code piece. This is the code for the beloved MK-58 pistol used by secoffs.

• type: entity
  name: mk 58
  parent: BaseWeaponPistol
  id: WeaponPistolMk58
  description: A cheap, ubiquitous sidearm, produced by a NanoTrasen subsidiary. Uses .35 auto ammo.
  components:
  • type: Sprite
    sprite: Objects/Weapons/Guns/Pistols/mk58.rsi
    layers:
    • state: base
      map: ["enum.GunVisualLayers.Base"]
    • state: mag-0
      map: ["enum.GunVisualLayers.Mag"]
  • type: Clothing
    sprite: Objects/Weapons/Guns/Pistols/mk58.rsi
  • type: Gun
    fireRate: 5
    availableModes:
    • SemiAuto
      soundGunshot:
      path: /Audio/Weapons/Guns/Gunshots/mk58.ogg

It looks like a lot, but let's break it down.

Here is the start of a basic YML file. For the most part, every YML piece will start with these. They define what something is, what it's ID is, it's parent, description, and components.

• type: entity

  name: # What will your object be named?? Only for ingame display.

  parent: # This defines what your object is a "child" of. All this means is that it automatically takes all the components from it's
  parent and uses them inherently. Don't worry, though, you can still edit existing components as a child. It saves a LOT of
  time doing this.

  id: # This defines your object's ID. Generally the ID is used for other ingame references like parents, loadouts, or any other times
  this object is referenced in another file. Consider it the name of the object as far as the code cares. Generally follows certain
  naming schemes. For example, this is WeaponPistolMK58 because it's a weapon in the pistols.yml file.

  description: # What will appear when you inspect this item ingame?

  components: # we'll get further into this next. Pretty much sets up the framework for components to be listed.

COMPONENTS:

Components are used by YAML code to help further define what an object does. So far, we have the name, id, description and parent of your object. That's nice and all, but what if we want it to do something unique that the parent doesn't do? Well, welcome to the world of components!

These are the components used by the MK58's YAML file

• type: Sprite
  sprite: Objects/Weapons/Guns/Pistols/mk58.rsi
  layers:
  • state: base
    map: ["enum.GunVisualLayers.Base"]
  • state: mag-0
    map: ["enum.GunVisualLayers.Mag"]
  • type: Clothing
    sprite: Objects/Weapons/Guns/Pistols/mk58.rsi
  • type: Gun
    fireRate: 5
    availableModes:
    • SemiAuto
      soundGunshot:
      path: /Audio/Weapons/Guns/Gunshots/mk58.ogg

Let's break it down again.

- type: Sprite # This defines the sprite for the object. What does it look like? for example, this one's file path is
Objects/Weapons/Guns/Pistols/mk58.rsi, like we talked about earlier. All the .PNGs for the MK58 is in mk58.rsi.
sprite:
layers: # This just says what part of the sprite, if multi-layered, will be on what layer. It repeats twice because the MK58 has two
layers.
- state:
map:
- state:
map:

- type: Clothing # Used for clothing objects. Since the MK58 can be worn in your belt slot, it has a unique sprite for that situation.
sprite: # as defined here.
# NOTE: because the MK58 is a child of BaseWeaponPistol, the ability to be worn on your belt is inherent. Normally it
would be listed here under the clothing component, however.

- type: Gun # Used for guns. Simply defines the fire rate (shots per seconds) and the firing modes that it can do.
fireRate:
availableModes:
- SemiAuto

**soundGunshot:** # What sound does it make when it's fired?
  **path: /Audio/Weapons/Guns/Gunshots/mk58.ogg** # Said sound

These are some examples of components in action, sanding a rough YML file down into a more focused object that has it's own sprites and sounds. There are a LOT of components. Remember if you want an object to do something that something else partly does, there's zero shame in going over to it's YML to figure out what components make it tick and using those. SS14 is all about modularity.

And that's pretty much it for YML files, for objects anyways. There are different types for different things like stacks, shops, enemies, but they're all formatted extremely similarly. Nice job!!

.RSI FOLDERS AND .JSON FILES

This stuff is arguably simpler than YAML, because it's almost all copy-paste.
Again, .RSI folders are just there to hold sprites and the .JSON file. They are what are referenced later in the code by YML files.

Now for JSON files. Like we said, they're like a translator, turning the PNGs into something usable by the code by giving them names and animations. Here's the JSON file for RTG.RSI, the folder containing all the sprites for RTGs.

{
"version": 1,
"license": "CC-BY-SA-3.0",
"copyright": "Taken from tgstation at commit tgstation/tgstation@99ed48c, rtg_damaged by Peptide90", # The copywrite, if you make a unique sprite feel free to put your name.
"size": {
"x": 32, # the size these files are. MAKE SURE your files are whatever size is listed.
"y": 32
},
"states": [
{
"name": "rtg" # These are JUST the names of the files. It just defines the name again so it can be used by the code.
},
{
"name": "rtg_open"
},
{
"name": "rtg_damaged",
"delays": [
[
0.3, # Stuff like this just means that RTG damaged has a animation that loops. So this part here just says "how long will each
bit of the animation display before moving to the next?"
0.3,
0.3,
0.3
]
]
},
{
"name": "rtg_glow",
"delays": [
[
0.2, # Same thing here, animation. RTGs actually layer two animations on top of each other and use those in tandem. That
part's defined in the YML under sprite layers like we talked about earlier.
0.2,
0.2,
0.2
]
]
}
]
}

And that's pretty much it for basic contributing! If you have more ideas or questions on how to do things, fire away. I want to help y'all learn so that you can make your own wonky creations for fun, and also so i can totally not use you for free labor.

With this knowledge, you can now make whatever kind of item you want and have it's own sprite appear ingame! You can make an apple that distorts reality and shoots lightning, or a frag grenade that shoots out clown horns! This stuff is the major framework for contribution and allows you to do so many things with minimal effort compared to other types of code. Remember to ask questions, as we didn't cover everything about everything, but you should be able to reference other files to figure out how certain things work.

You've graduated Contributionary Corps 101!