/tg/Station 13

The wiki guide has some basic guides on how to write code byond code, but no where does it ever say how tg is coded.

What files control what, what things are called when etc.

I just can't make any sense of this huge blob of files and code that is the tg code.

An example on how to actually implement some basic things roughly from start to finish would also make things A LOT easier to understand.

You're basically asking how do I do everything.
I'm no expert but if you search a proc that's being referenced, back to it's source, you'll often find comments explaining it.
Doesn't work everytime but when I'm trying to figure something out that's where I start and sometimes finish.

this also might help, it's where they hide the secret translations for some of their more arcane procs
https://github.com/tgstation/-tg-statio ... /__DEFINES
(There is more like this, basically _define what you're trying to understand and hope for comments)


I dabble, and have never coded anything whatsoever, so take what said here with that in mind.
This is just what I've found in my searches to try to understand a few things better

1. find easy-looking bug
2. join #coderbus
3. try to fix bug
4. repeat until you are a god

There's very little documentation on /tg/ code, which means it's pretty hard to learn normally. I taught myself, for instance. BYOND is such a simplistic language that if you've had any experience in code you grasp it very quickly. The issue with an open-source game is that there's very little generalized file structure. For instance, you can find a multitool in /code/game/objects/items/devices, but clothing is stored in an entirely different folder, in /code/modules/clothing. Using CTRL+F and searching included files will be a lifesaver if you're looking for a specific item.

The bad thing about Space Station 13 is that there are a lot of procs unique to it, and it can be hard to absorb. Your early days will consist of a lot of copy-pasting and editing to what you want. It's impossible to memorize so many procs early on unless you're a prodigy. The good thing about it is that /tg/ is an open-source repository, meaning you can look at any of the code and make small edits to help you better understand it. A good place to start is looking around for issues with the Easy Fix label on https://github.com/tgstation/-tg-station/issues. Feel free to join the #coderbus channel on https://rizon.net/chat for any questions you might have.

Here's the basics of how files are organized:

• -tg-station
  • _maps (where all the maps are)
  • icons (where all the sprites are)
  • config (all the config files, list of admins, game options. If you wanted a different bomb cap for your server, you'd look in there)
  • html
    • changelogs (where you put your changelog when you change the code)
  • sound (all the sound files)
  • code (where all the code is, if you're not editing sprites, sounds or maps this is where all your changes will be)
    • ATMOSPHERICS
    • LINDA (fire code)
    • __DEFINES (where most defines are stored)
    • __HELPERS (helper procs, i.e. useful procs used in lots of places in the code (e.g. math functions)
    • _globalvars (where most globally defined vars are)
    • _onclick (click code)
    • controllers
    • datums (the data types)
    • game
      • area
      • machinery (the machine code, i.e. computers, air alarms, SMES, constructable machines, doors, etc)
      • mecha (mech code)
      • objects (where most /atom/movable/obj types are)
        • effects (foam, smoke, sparks, bloodstains, ...)
        • items (where most /atom/movable/obj/item types are)
        • structures (where most /atom/movable/obj/structure types are, i.e. windows, grille, chair, crate, closet, toilet, mirror, statues, etc)
      • turfs (where all the atom/turf types are, i.e. space turf, wall turfs, floor turfs)
    • modules (this is all the specific code modules, for example mob code, reagent code, clothing code)
      • food&drinks
      • admin
      • client
      • mob (mob code)
      • reagents (reagents code used to handle chemicals and stuff)
      • projectile (projectile code, contains guns and their projectiles)
      • power (code related to electrical power (APC, wires, singularity stuff)

Also, here's all the basic object types:

• /datum (data stuff)
• /datum/atom is the ancestor of all mappable objects (you can use /atom instead of /datum/atom)
• /datum/atom/turf is the "tiles" of the games, basically floors, walls, space, etc (you can use /turf instead of /datum/atom/turf).
  Example: /turf/simulated/wall/mineral/gold
• /datum/atom/area (area stuff) (you can use /area instead of /datum/atom/area)
  Example: /area/quartermaster/office
• /datum/atom/movable is the mappable objects capable of motion
• /datum/atom/movable/mob is "mobile objects", basically living being, ghosts and new players (you can use /mob instead of /datum/atom/movable/mob)
  Example: /mob/living/carbon/human
• /datum/atom/movable/obj are "objects" (you can use /obj instead of /datum/atom/movable/obj)
  Example: /obj/item/weapon/screwdriver

Those types are native to byond. Now here's the basic ones specific to space station 13:

Obj

• item
  • weapon
• effect (sparks, foam, smoke, blood stain)
• mecha
• machinery
  • clonepod (cloning pod)
  • vending (vending machines)
  • computer
• structure
  • window
  • grille
  • closet
    • crate
  • stool
    • bed
      • chair

Mob

• living
  • carbon
    • monkey
    • human
    • alien (xenomorph, larva)
  • silicon
    • robot (cyborgs)
    • ai
  • simple_animal (mouse, corgi, cult constructs, maintenance drone, space carp, etc)
• dead
  • observer (ghosts)

Turf

• space (space tiles)
• simulated (turf with atmos simulation)
  • floor
    • plating
  • walls

One should note some things

/obj/ are things that can exist in the world, but not normally be controlled by a player
/mob/ are things that can exist in the world, but can be controlled by a player.

This is the byond distinction, but code exists to allow a mob to possess an obj.

/obj/item <--- this one got me confused for a moment, but items are anything that can be picked up or helded. A syndibeacon is an item, the bomb it spawns when you click on it is not.

Fixing bugs and making minor changes is the best way to get into it.

I recommend learning a few things about object oriented programming principles before you start implementing new stuff. BYOND is quite different from Java and C++ in some regards, but the principles of OOP still apply.

Ideally, learning a new language and its peculiarities should only be a small task. Basic programming skills carry over to any language you work with.

also install notepad++ if you're on windows.
use that to edit the code and to search the code, it's great.
notepad++ has a "define your own language" feature which allows syntax highlighting for arbitrary languages.
here's an XML file for DM:
http://pastebin.com/abzbCU1n

Copy paste shit wildly and pretend you know what you're doing.

The best way is to start simple. Code some items which are like, reskins or whatever, like a new pet tame goliath for the QM or something.
Then begin working on something new, an idea from the idea forum. Thrash out some pseudocode which looks like it should work according to some similar code you've seen.
Upload it to a piratepad, and post it in #coderbus
The horrified screams of the people within when they see this pseudocode will instruct you on how the system you just mushed works.

If you know something you really want to do but don't know how to go about doing it exactly, feel free to ask.

I spent a pretty good length of time just reading and trying to understand everything. It was kinda slow but I had success. I think most people would do better by getting their hands dirty and trying stuff out.

Linked Lists OP

Linked Lists

oranges wrote:Linked Lists OP

Linked Lists

recursive data types in general

just don't overdo it on the complexity

linked lists murder your cache performance bruh

good thing that byond is so shit that it doesnt have any cache performance anyway.

also byond lists are not linked lists, theyre red-black trees.

you can define your own (recursive) data types with /datums so you could totally write linked lists if you'd want to

whether it's a good idea, on the other hand...

One thing I think it's important to point out is that code readability is all over the place depending on where you look, If you just open a random file and it all seems too complicated don't despair, you may have just gotten unlucky.

I'm gonna pimp out my oldest codebaby on this one:

https://github.com/tgstation/-tg-statio ... atebomb.dm

I wrote most of that code when I still had a pretty tenuous grip on DM so it's written pretty directly, if only because at the time I had no knowledge on how to make it flowery impenetrable garbage.

Slot machines are theoretically some of the cleanest code you'll find because I made them while being heavily scrutinized by Gia and Rock, you could try looking at those.