fill out the rest of general development

src/en/general-development/codebase-info/acronyms-and-nomenclature.md

@@ -1,3 +1,26 @@
-# Acronyms & Nomenclature
+# Acronyms and Nomenclature
 
-{{#template ../../templates/porting.md}}
+| Shorthand                | Meaning                                                                                                        |
+|:------------------------ |:-------------------------------------------------------------------------------------------------------------- |
+| SS14                     | Space Station 14. Remake of Space Station 13 (SS13).                                                           |
+| BYOND                    | The game engine for SS13.                                                                                      |
+| RobustToolbox, Engine    | SS14's game engine.  (Think BYOND).                                                                            |
+| Content, Content Pack    | The "game" running on RobustToolbox.  (Think SS13).                                                            |
+| CVar                     | Convar/Console Variable. Configurable value that you can change in the config files or through the console.    |
+| .yml, YAML               | YAML Ain't Markup Language. Used to define prototypes.                                                         |
+| .toml, TOML              | Tom's Obvious Minimal Language. Like YAML but for config.                                                      |
+| ECS                      | Entity Component System                                                                                        |
+| IoC                      | [Inversion of Control](../../robust-toolbox/ioc.md)                                                            |
+| .dmi, DMI                | BYOND/SS13's sprite file format. Converted to an RSI for our usage.                                            |
+| .rsi, RSI                | Robust Station Images. SS14's image "file" format (actually a folder).                                         |
+| PVS                      | Potentially Visible Set. Stops the server from sending out-of-range entities to clients.                       |
+| PJB, PJB3005             | Pieter-Jan Briers. Supreme ^Nerd^ overlord of SS14.                                                            |
+| VSC, VSCode              | Visual Studio Code. Not the same as VS.                                                                        |
+| VS                       | Visual Studio Community 2017/19. Not the same as VSC. The IDE for people who can't get a Rider license.        |
+| Rider                    | [A crossplatform IDE for C#.](https://www.jetbrains.com/rider/) (Can be obtained for free as a student).       |
+| Watchdog                 | SS14 Server Watchdog. Used for dedicated server logging, updating and general management.                      |
+| Lidgren                  | Networking library.                                                                                            |
+| Box2D                    | The basis for SS14's (heavily modified) physics system.                                                        |
+| Avalonia                 | UI framework used for the launcher.                                                                            |
+| Postgres, SQLite         | Databases.                                                                                                     | 
+| EntityUid                | Entity Unique Identifier                                                                                       |

src/en/general-development/codebase-info/codebase-organization.md

@@ -1,3 +1,50 @@
 # Codebase Organization
 
-{{#template ../../templates/porting.md}}
+## Projects
+
+SS14 and RobustToolbox are split into several different projects. The main ones you'll care about are the `Client`, `Shared`, and `Server` projects. Other projects are for smaller things like integration tests, benchmarks, or database-specific code. 
+
+`Client`, `Shared`, and `Server` are each packaged into different 'assemblies', which is basically .NET talk for executables or shared libraries.
+
+The `Client` project in both Robust and SS14 contains client-specific code, like UI. This assembly is only sent to the client, the person actually playing the game.
+
+The `Server` project contains server-specific code that no specific client should be able to interact with, like atmospherics or botany. This assembly is only located on the game server.
+
+The `Shared` project contains shared code that can be used by the client or the server. This assembly is not executable, and it relies on the client or server to call functions in it or use data classes located within it. The purpose of shared is to allow for network prediction (where the client and server run the same code, to make things smoother) as well as to specify shared data classes, like network messages, so that the client and server can speak to eachother effectively.
+
+Shared code is only allowed to access other shared code, not client or server code. However, client and server code are always allowed to access shared code.
+
+## Game Code
+
+In SS13, all game code is randomly thrown around under `code/`, and instead of grouping by relevance to systems, is grouped by abstract things like whether the file is a list of constants or whether a file pertains to a master controller subsystem. In SS14, we first delineate by which game system we're working with (atmos/botany/buckling, etc) and then by the classes needed for it, which is much easier for anyone actually trying to work within a single system.
+
+`Content.Client`, `Content.Shared`, and `Content.Server` all follow this organization. RobustToolbox's equivalents do not currently, but will in the future.
+
+- All game code will be organized in folders directly under Content.Client/Shared/Server etc.
+- Game code folders are split into Components, EntitySystems, Visualizers, UI, Prototypes, etc
+- If there would only be one file in a folder, it doesn't need a folder (unless that file would go directly into the project's top directory, which is undesirable).
+- Do not use 'misc' folders; misc folders are hell for organization and its completely arbitrary what goes inside them and what doesn't. You can encapsulate smaller game systems inside larger game systems if it unambiguously makes sense (Atmos -> Piping), but don't just slap all the smaller game systems into a misc folder.
+
+This structure should hopefully be very clear after working with it or seeing examples.
+
+A real example, under `Content.Server` at `da11cbd8e6bef3373ec1f570df7d7b9155a3890f`
+
+![](../../assets/images/codebase-server-example.png)
+
+- Atmos is a fairly large game system. It has many folders, and many files that do not need to go in these folders.
+- Botany is a smaller game system. However, it only has one folder for Components since that's all that's really there.
+- ItemCabinets are a very small game system. They just have a component and EntitySystem, and thus do not need folders for each.
+
+## Resources
+
+The resources folder is another area where we hope to improve over the organization structure of SS13 codebases.
+
+### Entity Prototypes
+
+New folders should usually only be created for a new parent type. If you find something that can be pulled out into a parent prototype, it should go in its own folder.
+
+Parent prototypes should be contained in `base.yml` in this folder, while other prototypes go in a different file.
+
+Not everywhere is organized like this; however, the `Structures` folder is.
+
+This was chosen to make the directory structure mirror the prototype inheritance tree, making it obvious where to place new prototypes as well as being fairly unambiguous when choosing to create new folders.

src/en/general-development/tips/config-file-reference.md

@@ -1,3 +1,35 @@
 # Config File Reference
 
-{{#template ../../templates/porting.md}}
+Config files are [TOML](https://toml.io/), a relatively modern and simple config file format.
+By default, the server loads the config file from `server_config.toml` next to the executable. The client loads it from `GameControllerOptions.ConfigFileName` (defaults to `client_config.toml`) in the [User Data Directory](../../robust-toolbox/user-data-directory.md). 
+
+Config files store "CVars", which is short for "console variable" but may also mean "config variable" depending on how much you care about being accurate to Quake or something. It doesn't really matter. Hey it's short to write.
+
+## TOML Crash Course
+
+TOML is basically just INI but somewhat more well-specified and hipster. You put headings in square brackets and keys below that. We do not use more advanced TOML stuff than shown here (since it sucks):
+
+```toml
+[net]
+port = 12345
+
+[game]
+hostname = "honkhonk"
+maxplayers = 64
+
+[log]
+enabled = true
+```
+
+When a CVar is referred to as `net.port`, that means put `port = foo` under the `[net]` header. For cases where you directly refer to a cvar in full (such as the `cvar` command) you write out the full name (like `cvar net.port`).
+
+## CVar reference
+
+if you want to find a reference of all CVars available in the game/engine, your best bet is to check the game and engine code: [`CCVars.cs` for Space Station 14](https://github.com/space-wizards/space-station-14/blob/master/Content.Shared/CCVar/CCVars.cs), [`CVars.cs` for Robust](https://github.com/space-wizards/RobustToolbox/blob/master/Robust.Shared/CVars.cs). It should be pretty easy to read.
+
+## Ways of specifying CVars
+
+* You can put them in the server or client config file and have it be loaded automatically.
+* You can use the `cvar` command to view and set CVars at runtime. Note that not all CVars support changing them live: effects may include it working fine, server exploding, or nothing happening.
+* You can pass `--cvar foo.bar=123` as command line argument to the client or server to override a CVar at start time. This also overrides any values set in config files.
+* You can use the `ROBUST_CVARS` environment variable, which is semicolon-sepated like so: `ROBUST_CVARS=foo.bar=1234;foo.baz=hello there`. You probably don't want to accept any insecure input into this, since it's pretty basic and can't be escaped properly.

src/en/general-development/tips/prs-with-engine-changes.md

@@ -1,3 +1,54 @@
 # PRs With Engine Changes
 
-{{#template ../../templates/porting.md}}
+The engine still has many areas to improve, so it's unavoidable that some some changes to content will require changes to the engine as well.
+
+## Working in the submodule
+
+The engine does not work on its own. Without a game like SS14 to provide content, the engine will not do anything. To be able to test and work on your changes it is thus recommended that you directly work on the engine submodule inside your SS14 repo.
+
+If you are unfamiliar with **Git submodules**: Git submodules are basically just Git repositories, tracked inside other Git repositories. For example, SS14 has a submodule pointing to Robust. 
+
+Because the submodule is still a fully fledged Git repositories, you can work out of it like any other repo: Make commits, branches, push, pull, etc... The parent repository tracks the currently checked out commit of the child submodule, and does not concern itself with anything else happening in the submodule.
+
+First, you will need to fork the [engine](https://github.com/space-wizards/RobustToolbox). You can then change your git remotes inside the submodule so that you can work against your fork:
+
+```bash
+# Go to branch master
+git switch master
+# Rename "origin" (the default remote, keeping track of space-wizards) to "upstream".
+git remote rename origin upstream
+# Add your own fork as "origin" remote.
+git remote add origin https://github.com/<your username>/RobustToolbox.git
+# Master will still track upstream (so you can just run git pull on it)
+# and any branches you push to origin will go to your fork.
+```
+
+Second of all, you will need to disable submodule autoupdate. By default, the build system automatically updates the submodule (so that people who *don't* care to modify the engine don't have to manually run `git submodule update` constantly). This however gets in your way if you're trying to make changes to the engine, as it will constantly reset you to master! To disable this perhaps feature, put an empty file called "`DISABLE_SUBMODULE_AUTOUPDATE`" in the `BuildChecker/` folder at the root of the SS14 project (not inside `RobustToolbox/`). Also make sure it doesn't have a `.txt` at the end or something.
+
+## Making the PR
+
+When making your PR, you will want to make a separate PR in the engine repo and the main repo.
+
+**Do not actually commit a change to the checked out submodule commit in your main content PR, you should just leave it as uncommitted while you develop it.** It's a constant cause of merge conflicts, and we will handle things when we merge.
+
+### My build fails!
+
+To have the build system use your engine changes when building your main PR, you need to put "Requires <PR>" in the PR message.
+
+For example, if your engine PR is #1234, then your main PR message would be:
+
+```
+This is my PR that requires an engine change.
+
+  * Broke something
+  * Fixed something
+
+Requires https://github.com/space-wizards/RobustToolbox/pull/1583
+```
+
+The supported formats can be found at https://github.com/space-wizards/submodule-dependency
+
+
+## Guidelines for engine changes
+
+Try to avoid any breaking changes that make future engine versions incompatible with old game versions. This isn't a massive problem due to how we version engine builds, but it still causes a very awkward updating dance when we try to update the submodule in content. Approaches like marking something `[Obsolete]` are far preferred to outright removing something when it isn't necessary anymore.