Fix typos

src/en/community/maintainer.md

@@ -1,3 +1,3 @@
 # Maintainer
 
-This section contains information on Maintaier and PR-Review Policies, **as it pertains to Wizards Den servers, hosted by Space Wizards.** These policies do not apply to other servers, and may be waived in exceptional circumstances.
+This section contains information on Maintainer and PR-Review Policies, **as it pertains to Wizards Den servers, hosted by Space Wizards.** These policies do not apply to other servers, and may be waived in exceptional circumstances.

src/en/community/projectmanager.md

@@ -4,18 +4,18 @@
 
 Project Managers handle a variety of responsibilities when it comes to the SS14 game and community. If there is policy or a high-level decision being made, the project management team will be involved. PM is less of a defined role and more of a higher responsibility with different PMs handling different elements of the game and community. In general if a situation needs escalating then short of involving a Wizard, PMs are where the buck stops so to speak.
 
-The PM team does not appeal bans or get involved in individual player/game disputes unless said dispute is creating an issue of safety or harassment (However some PMs are also game admins and may act in this capacity). The admin team should be your first point of contact for these sorts of issues, with PM's being the nuclear option in an emergency situation where you have fears for your, or another community memeber's safety.
+The PM team does not appeal bans or get involved in individual player/game disputes unless said dispute is creating an issue of safety or harassment (However some PMs are also game admins and may act in this capacity). The admin team should be your first point of contact for these sorts of issues, with PM's being the nuclear option in an emergency situation where you have fears for your, or another community member's safety.
 
 ## Areas of Responsibility
 
 All Project Managers have the same level of authority and autonomy when it comes to addressing issues, however some PMs prefer to or are more experienced in handling particular issues. In an emergency any PM will be able to help you, but generally a PM with the appropriate area will be able to address your issue faster and more accurately. *Although, if you message the wrong PM don't worry we all talk with each other so they'll be able to help you or forward you along to someone who can, it's just faster to start with a PM from that area!*
 
-Here is a list of PM's and their responsiblities. Some responsibilities such as Hub Administration and Sensitive Issue handling are not listed publicly to prevent targeted harassment.
+Here is a list of PM's and their responsibilities. Some responsibilities such as Hub Administration and Sensitive Issue handling are not listed publicly to prevent targeted harassment.
 This page may sometimes be out of date, for the most recent responsibilities check discord (If this page is out of date ping @Jezithyr on discord or let a maintainer know).
 
 | Responsibility | Description | Members |
 |---|---|---|
-| Wizards | Highest level of staff in SS14. They are responsibly for handling business-to-business, fincanical, and legal matters. If you think you need to ping a wizard you don't, just talk to a PM instead. | PJB, Zoldorf, Bobda, DrSmugleaf |
+| Wizards | Highest level of staff in SS14. They are responsibly for handling business-to-business, financial, and legal matters. If you think you need to ping a wizard you don't, just talk to a PM instead. | PJB, Zoldorf, Bobda, DrSmugleaf |
 | Project Lead | The GOAT. The supreme nerd overlord. Also someone who is very busy and unless you need help with something very niche and specific, you're better off asking another PM/Maintainer. | PJB |
 | PM Team Lead | The ~~Queen~~ benevolent leader of the PM team. She manages internal disputes and helps the PM team stay on track! | DrSmugleaf |
 | Head Admins | The triumverate in-charge of the admin team. These are the people who *write the rules/policy for the admins* not the people to ask to appeal your ban. | Skarlet, Nairod, Chief_Engineer |

src/en/community/space-wizards-hub-rules.md

@@ -92,7 +92,7 @@ Breaking one of these rules will lead to your community receiving at most one st
 **2.1. Keep your server names and descriptions clean**
 - They are visible to every player who uses the hub.
 - Keep it safe for work and free from vulgarity.
-- No bigotry, hate speech, descrimination, etc...
+- No bigotry, hate speech, discrimination, etc...
 
 **2.2. Do not impersonate other servers, developers, or organizations.**
 - If there is a reasonable way for players to be confused about the affiliations of your server, you're probably breaking this.

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

@@ -10,7 +10,7 @@ The `Client` project in both Robust and SS14 contains client-specific code, like
 
 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.
+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 each other 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.
 

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

@@ -43,7 +43,7 @@ All of the variables are named in a self-documenting way (*R* gets a pass becaus
    float fractionalPressureChange = Atmospherics.R * (outlet.Air.Temperature / outlet.Air.Volume + inlet.Air.Temperature / inlet.Air.Volume);
 ```
 
-Because this only explains what the code is literally doing, which you could have gathered from any cusory reading of the code. **However, you still have absolutely no idea what this code is doing and why**, even though the code is self-documenting.
+Because this only explains what the code is literally doing, which you could have gathered from any cursory reading of the code. **However, you still have absolutely no idea what this code is doing and why**, even though the code is self-documenting.
 
 You don't know where this magic formula came from, what it's trying to accomplish, or even if the formula is correct. Therefore, this needs to be documented:
 
@@ -221,7 +221,7 @@ public SpriteSpecifier Icon { get; } = SpriteSpecifier.Invalid;
   <summary>RSI meta.json (click to expand)</summary>
 
 - The order of fields should be `version -> license -> copyright -> size -> states`.
-- JSON should not be minified, and should follow normal JSON quality guideliens (egyptian brackets, etc)
+- JSON should not be minified, and should follow normal JSON quality guidelines (egyptian brackets, etc)
 
 Example:
 
@@ -269,7 +269,7 @@ _adminLogs.Add(LogType.MyLog, LogImpact.Medium, $"{entityManager.ToPrettyString(
 
 ### Optional Entities
 If you need to pass "optional" entities around, you should use a nullable `EntityUid` for this.
-Never use `EntityUid.Invalid` to denote the abscence of `EntityUid`, always use `null` and nullability so we have compile-time checks.
+Never use `EntityUid.Invalid` to denote the absence of `EntityUid`, always use `null` and nullability so we have compile-time checks.
 e.g. `EntityUid? uid`
 
 ## Components
@@ -518,7 +518,7 @@ You may use `PhysicsComponent` static body anchoring but *only* if you know what
   name: 'Spessman's Smokes packet'
   description: 'A label on the packaging reads, 'Wouldn't a slow death make a change?''
 ```
-- Dont specify textures in abstract prototypes/parents.
+- Don't specify textures in abstract prototypes/parents.
 - You should declare the first prototype block in this order: `type` > `abstract` > `parent` > `id`  > `name` > `description` > `components.`
 - New components should not have an indent when added to the `components:` section.
     This

src/en/general-development/codebase-info/pull-request-guidelines.md

@@ -88,7 +88,7 @@ The Changelog is for *players* to be aware of new features and changes that coul
 
 When writing your changelog entries, please follow these guidelines:
 
-1. **Log entries should be complete, gramatically-correct sentences.** They should begin with a capital letter and end in a period.
+1. **Log entries should be complete, grammatically-correct sentences.** They should begin with a capital letter and end in a period.
 
    - Not so good: "fixed reflected projectiles dealing stamina damage" This sentence does not begin with a capital letter, does not end with a period.
 
@@ -98,7 +98,7 @@ When writing your changelog entries, please follow these guidelines:
 
    - Not so good: "A craft for cloth consisting of silk." This is not a complete sentence.
 
-2. **Log only changes with significant in-game impact.** This may include new features or changes or tweaks to existing features that affect balance. Minor changes to object apperances and descriptions typically do *not* affect how you would play the game. Changelog entries for major sprite updates are appropriate.
+2. **Log only changes with significant in-game impact.** This may include new features or changes or tweaks to existing features that affect balance. Minor changes to object appearances and descriptions typically do *not* affect how you would play the game. Changelog entries for major sprite updates are appropriate.
 
    - Good: "The R&D server can be deconstructed. Be warned: this resets all unlocked technology, points, and the current discipline." Without the Changelog entry, players may not know that R&D servers can now be deconstructed. It also provides them enough warning about losing technology so that they don't accidentally get surprised.
 
@@ -116,7 +116,7 @@ When writing your changelog entries, please follow these guidelines:
    - Not so good: "Added candy bowls for waiting lines." Who is doing the adding?
    - Good: "Candy bowls can now be found near waiting lines." The subject is now "candy bowls". Each sentence has a subject and a verb.
 
-4. **Be concise and avoid wordy, "IC" changes.** Players should be able to understand the jist of the changes by skimming the Changelog. "IC" changes are harder for players to read and understand what the change was. Make changes concise and to the point. If they need more information, they can consult the guidebook. Avoid spamming multiple related changes across several different lines. If several security weapons were rebalanced, just say that to make players aware.
+4. **Be concise and avoid wordy, "IC" changes.** Players should be able to understand the gist of the changes by skimming the Changelog. "IC" changes are harder for players to read and understand what the change was. Make changes concise and to the point. If they need more information, they can consult the guidebook. Avoid spamming multiple related changes across several different lines. If several security weapons were rebalanced, just say that to make players aware.
 
    - Not so good: "Central has distributed a new subversion of the standard particle accelerators. Nothing exciting, but they have brought back the old wiring layout. Apparently some of the newer versions were having firmware issues and it was more reliable. Keep on eye on it while it''s running will you? We don''t want an intern disabling the safeties and frying their face off." Do you understand what changed? Even the author thinks the change is "nothing exciting."
 
@@ -137,4 +137,4 @@ When writing your changelog entries, please follow these guidelines:
 
    - Not so good: "Can you believe it? Arachnid re-rework just dropped! Check the PR for more details"
 
-   - Not so good: "Arachnids have new sprites for being creampied." *crampied* has another, unfortunate meaning that undermines the professional tone of a Changelog entry.
+   - Not so good: "Arachnids have new sprites for being creampied." *creampied* has another, unfortunate meaning that undermines the professional tone of a Changelog entry.

src/en/general-development/feature-proposals.md

@@ -37,9 +37,9 @@ These don't have to be discrete sections and shouldn't be. When you're detailing
 
 ## Does my idea really need a design doc?
 
-It depends on the scale, and pervasiveness of whatever you're thinking of proposing. If it's something like adding a single gun or a couple simple plants it probably won't. On the other hand if you are adding an entire subdepartment ala anomalies/xenoarchaeology, or something on the order of reworking the entirity of botany or chemistry it certainly will.
+It depends on the scale, and pervasiveness of whatever you're thinking of proposing. If it's something like adding a single gun or a couple simple plants it probably won't. On the other hand if you are adding an entire subdepartment ala anomalies/xenoarchaeology, or something on the order of reworking the entirety of botany or chemistry it certainly will.
 
-A good rule of thumb if the new feature or rework you have in mind would require adding or reworking a page of the guidebook or one of the feature docs on this site then it probably needs a design doc. Same if the proposal could be accurately described as 'reworking the entirity of X'.
+A good rule of thumb if the new feature or rework you have in mind would require adding or reworking a page of the guidebook or one of the feature docs on this site then it probably needs a design doc. Same if the proposal could be accurately described as 'reworking the entirety of X'.
 
 ## Will my design doc get accepted?
 

src/en/general-development/setup/git-for-the-ss14-developer.md

@@ -28,7 +28,7 @@ I won't have steps for these (I'm recommending these after I initially wrote thi
 - [Fork](https://git-fork.com/) -- fast and extremely ergonomic GUI, my personal favorite. "Non-free", but it's WinRAR-level non-free, so it's basically free. Has support for partial staging of
 - [Sublime Merge](https://www.sublimemerge.com/) -- very similar to Fork, looks and feels great and I've gotten a lot of recommendations for it, though I haven't used it much. Also has support for partial staging.
 
-Most IDEs have some form of Git integration aswell. [Jetbrains Rider](https://www.jetbrains.com/rider/)'s Git integration is really good (and I personally recommend Rider for everything SS14-development related). I don't recommend Visual Studio's Git integration, because it's.. not very good.
+Most IDEs have some form of Git integration as well. [JetBrains Rider](https://www.jetbrains.com/rider/)'s Git integration is really good (and I personally recommend Rider for everything SS14-development related). I don't recommend Visual Studio's Git integration, because it's.. not very good.
 
 While you're here, install `Python 3.7+` as well if you don't have it already. You can do that [here](https://www.python.org/) for Windows and Mac, and if you're on Linux you almost certainly have Python installed already. If you don't, figure it out yourself, dork!
 
@@ -131,7 +131,7 @@ Then, we'll enter the command for cloning **our** remote repository--not the `sp
 Then **c**hange **d**irectory using:
 ``cd space-station-14`` 
 
-(This may be diffrent if you cloned another fork, it's almost always being the same as the repository name)
+(This may be different if you cloned another fork, it's almost always being the same as the repository name)
 
 Every Git command will look something like this--`git` and then a keyword like `add`, `commit`, `pull`, etc.
 

src/en/general-development/setup/server-hosting-tutorial.md

@@ -168,7 +168,7 @@ This is for people running their own codebase and server and/or those who want a
 [`SS14.Watchdog`](https://github.com/space-wizards/SS14.Watchdog/) (codename Ian) is our server-hosting wrapper thing, similar to TGS for BYOND (but much simpler for the time being). It handles auto updates, monitoring, automatic restarts, and administration. We recommend you use this for proper deployments.
 
 ### Installation
-[`Refeer to this`](https://docs.spacestation14.com/en/server-hosting/setting-up-ss14-watchdog.html) for intructions on building and configuring Watchdog.
+[`Refer to this`](https://docs.spacestation14.com/en/server-hosting/setting-up-ss14-watchdog.html) for instructions on building and configuring Watchdog.
 
 ### Server Instance Folder
 
@@ -211,7 +211,7 @@ Updates:
   Version: "foobar" # Version string to use.
 ```
 
-The watchdog will automatically host client binaries. Where does it pull them from? The `binaries/` folder in your server instance folder! Note that for this to work, the watchdog HAS to be publically accessible via `BaseUrl` in the config file.
+The watchdog will automatically host client binaries. Where does it pull them from? The `binaries/` folder in your server instance folder! Note that for this to work, the watchdog HAS to be publicly accessible via `BaseUrl` in the config file.
 
 You can edit the `Version:` specified in the config to tell the launcher that it should update the game next time you connect.
 

src/en/general-development/setup/setting-up-a-development-environment.md

@@ -46,7 +46,7 @@ And with that, your repo is now properly setup!
 4. Open Visual Studio
 5. Select `Open a project or solution`, then navigate to your cloned repository from above and open `SpaceStation14.sln`
 
-### Jetbrains Rider
+### JetBrains Rider
 * TODO
 
 ### VSCodium

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

@@ -32,5 +32,5 @@ if you want to find a reference of all CVars available in the game/engine, your
 * 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.
+* You can use the `ROBUST_CVARS` environment variable, which is semicolon-separated 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.
 * You can specify CVars via multiple environment variables with the `ROBUST_CVAR_` prefix (note the lack of plural from above). For example `ROBUST_CVAR_game__hostname=foobar`. A double underscore (`__`) is replaced with a `.`.