diff --git a/src/en/community/maintainer.md b/src/en/community/maintainer.md index ad40646de..ebc3ea2e6 100644 --- a/src/en/community/maintainer.md +++ b/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. \ No newline at end of file +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. \ No newline at end of file diff --git a/src/en/community/projectmanager.md b/src/en/community/projectmanager.md index 3cfaf04d5..c62817008 100644 --- a/src/en/community/projectmanager.md +++ b/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 | diff --git a/src/en/community/space-wizards-hub-rules.md b/src/en/community/space-wizards-hub-rules.md index 8c96e3eeb..3f6f6dad5 100644 --- a/src/en/community/space-wizards-hub-rules.md +++ b/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. diff --git a/src/en/general-development/codebase-info/codebase-organization.md b/src/en/general-development/codebase-info/codebase-organization.md index 31e020a30..e372cf04e 100644 --- a/src/en/general-development/codebase-info/codebase-organization.md +++ b/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. diff --git a/src/en/general-development/codebase-info/conventions.md b/src/en/general-development/codebase-info/conventions.md index 004bca8a5..5e7aa20c7 100644 --- a/src/en/general-development/codebase-info/conventions.md +++ b/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; RSI meta.json (click to expand) - 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 diff --git a/src/en/general-development/codebase-info/pull-request-guidelines.md b/src/en/general-development/codebase-info/pull-request-guidelines.md index adfcc46df..9292ed8ec 100644 --- a/src/en/general-development/codebase-info/pull-request-guidelines.md +++ b/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. diff --git a/src/en/general-development/feature-proposals.md b/src/en/general-development/feature-proposals.md index 8cb7346d1..3b38b6c0f 100644 --- a/src/en/general-development/feature-proposals.md +++ b/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? diff --git a/src/en/general-development/setup/git-for-the-ss14-developer.md b/src/en/general-development/setup/git-for-the-ss14-developer.md index 49e47db07..c0fd704ec 100644 --- a/src/en/general-development/setup/git-for-the-ss14-developer.md +++ b/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. diff --git a/src/en/general-development/setup/server-hosting-tutorial.md b/src/en/general-development/setup/server-hosting-tutorial.md index 06f208bac..54d96245a 100644 --- a/src/en/general-development/setup/server-hosting-tutorial.md +++ b/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. diff --git a/src/en/general-development/setup/setting-up-a-development-environment.md b/src/en/general-development/setup/setting-up-a-development-environment.md index 1061df895..09afb1340 100644 --- a/src/en/general-development/setup/setting-up-a-development-environment.md +++ b/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 diff --git a/src/en/general-development/tips/config-file-reference.md b/src/en/general-development/tips/config-file-reference.md index e60f43956..8efd4dc4e 100644 --- a/src/en/general-development/tips/config-file-reference.md +++ b/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 `.`. diff --git a/src/en/general-development/tips/troubleshooting-faq.md b/src/en/general-development/tips/troubleshooting-faq.md index 47dc97977..e89efbd88 100644 --- a/src/en/general-development/tips/troubleshooting-faq.md +++ b/src/en/general-development/tips/troubleshooting-faq.md @@ -14,11 +14,11 @@ We do not currently support running SS14/Robust natively on ARM macs. Install x6 Some written out error codes you may have, for ctrl+f'ing: "An attempt was made to access a socket in a way forbidden by its access permissions.", "Only one usage of each socket address (protocol/network address/port) is normally permitted." -By default, the game server needs ports 1212/UDP and 1212/TCP to start. Common occurence here can be *already running an SS14 server which uses the ports*. +By default, the game server needs ports 1212/UDP and 1212/TCP to start. Common occurrence here can be *already running an SS14 server which uses the ports*. #### Windows users -Installing **Docker for Windows** or something related seems to completely screw up the default dynamic port range on your system, and on top of that reserve a ton of ports via an always-running service. This means that *even when Docker isn't running* it, or *any app on your system* can randomely decide to register port 1212 for general purpose stuff. +Installing **Docker for Windows** or something related seems to completely screw up the default dynamic port range on your system, and on top of that reserve a ton of ports via an always-running service. This means that *even when Docker isn't running* it, or *any app on your system* can randomly decide to register port 1212 for general purpose stuff. If you want to verify this is the case, run `netsh int ipv4 show dynamicportrange tcp`. This *should* default to the following: diff --git a/src/en/general-development/work-groups.md b/src/en/general-development/work-groups.md index 1a1922512..6f5395562 100644 --- a/src/en/general-development/work-groups.md +++ b/src/en/general-development/work-groups.md @@ -2,7 +2,7 @@ Work Groups ===================== Work-groups are effectively the design equivalent to Code-Owners. Each work group is made up from maintainers that volunteer to upkeep the documentation and guidelines related to that area of the game. If you have a question about something related to one of the department/game areas feel free to message a member of its work group to get an authoritative answer. -Each work group is responsible for maintaining corresponding design and pr guidelines documents in the docs repo that outlines the current and intended design for that game area, along with what is acceptible design/quality for a PR in that game area. Maintainers that are not part of any work groups are generalists, and while they might not be fully up to date with the design of a game-area they can still help answer questions. +Each work group is responsible for maintaining corresponding design and pr guidelines documents in the docs repo that outlines the current and intended design for that game area, along with what is acceptable design/quality for a PR in that game area. Maintainers that are not part of any work groups are generalists, and while they might not be fully up to date with the design of a game-area they can still help answer questions. ## Current Work Groups diff --git a/src/en/meta/guide-to-editing-docs.md b/src/en/meta/guide-to-editing-docs.md index 0a32ffeac..63a9d6e27 100644 --- a/src/en/meta/guide-to-editing-docs.md +++ b/src/en/meta/guide-to-editing-docs.md @@ -8,9 +8,9 @@ If you want to get an idea of what features are at your disposal when writing do ## Making basic edits -If you just want to make a basic edit of a page, simply follow these steps--you dont need any of the fancy stuff talked about later: +If you just want to make a basic edit of a page, simply follow these steps--you don't need any of the fancy stuff talked about later: -1. Create an accout on GitHub, or log in if you already have one. +1. Create an account on GitHub, or log in if you already have one. 2. Fork the [space-wizards/docs](https://github.com/space-wizards/docs) repo on GitHub. diff --git a/src/en/space-station-14/departments/engineering/pow3r.md b/src/en/space-station-14/departments/engineering/pow3r.md index 41ccdc46e..4d92b6f24 100644 --- a/src/en/space-station-14/departments/engineering/pow3r.md +++ b/src/en/space-station-14/departments/engineering/pow3r.md @@ -9,26 +9,26 @@ Power is no longer buffered to shit with big batteries that can keep the station ## High level ### How Equipment Responds to power shortages -When the full amount of power is provided to a machine, it will operate as normal. When power is not available, the machine will completely turn off (should machines have power switches?) This unpowered state is the same state as an unachored consumer. +When the full amount of power is provided to a machine, it will operate as normal. When power is not available, the machine will completely turn off (should machines have power switches?) This unpowered state is the same state as an unanchored consumer. When a brownout occurs, the machine will respond depending on it's consumer type. Each machine has a power draw, a brownout only occurs for a machine if the power available to it is less than the draw amount. This is an independent event for every machine on the network. -* If the consumer is an analogue device like a motor/battery charger, it will reduce its speed (each machine will define what that means), but still operate as normal. Ususally these types of consumers will have no electronics on them. +* If the consumer is an analogue device like a motor/battery charger, it will reduce its speed (each machine will define what that means), but still operate as normal. Usually these types of consumers will have no electronics on them. * If the consumer is a digital device (most machines/terminals on the station, anything you can network to) it will have a built-in feature where it goes into a power cycle. It will turn itself off for ~5 seconds and then check to see if it can turn itself back on, repeating until power is restored. * If the consumer is a incandescent light bulb, then it will reduce it's light range, basically dimming. This is a linear relationship with the power deficit, it does not flicker. -* If the consumer is a flourescent lamp (most lighting in station, they use tubes) then it will flicker off/on with the frequency based on the deficit. When implementing this you probably want some randomness, and don't make it flicker too fast, this isn't a strobe. +* If the consumer is a fluorescent lamp (most lighting in station, they use tubes) then it will flicker off/on with the frequency based on the deficit. When implementing this you probably want some randomness, and don't make it flicker too fast, this isn't a strobe. * Advanced machines like the particle accelerator/emitters could have reduced fire rate depending on input power (the idea being that they need to charge internal capacitors). Should probably should have some form of curve here so that 50% power results in 25% firing speed or similar. Or actually accumulate charge inside of themselves to fire (invisible built-in capacitors), which would respond more realistically to frequent fluctuations, and prevent power pulsing metagame (see ONI exploits). -Some machines will have an internal battery entity that can store/provide power, which can mitagate these effects. +Some machines will have an internal battery entity that can store/provide power, which can mitigate these effects. ### Power storage on the station -Because of the size of the station and the number of high-power consumers on it, large power demand fluctuations are to be expected. Because most generators cannot respond quickly to this, power needs to be stored to provide consistant service to the rest of the station. +Because of the size of the station and the number of high-power consumers on it, large power demand fluctuations are to be expected. Because most generators cannot respond quickly to this, power needs to be stored to provide consistent service to the rest of the station. -The main storage device is the SMES. It is expected that engineering will have a group of these to buffer power into for the entire station. Other critical departments may have a single SMES nearby in maintnence, so that in the event of a power shortage they can still operate. Hallways and other low-priority areas will not have a dedicated SMES, so in the event of a power shortage they will turn off. +The main storage device is the SMES. It is expected that engineering will have a group of these to buffer power into for the entire station. Other critical departments may have a single SMES nearby in maintenance, so that in the event of a power shortage they can still operate. Hallways and other low-priority areas will not have a dedicated SMES, so in the event of a power shortage they will turn off. We want to avoid the overuse of this, so that power fluctuations on the station have a realtime effect on lights and machines. A nice balance will have to be struck here. @@ -56,7 +56,7 @@ Ideally the grid would self regulate to have lighting turn off (but nothing else I do propose swapping lighting and equipment though for spook vibes. -My current idea is that APCs distribute power to all enabled channels evenly, so if there's only 50% of required grid power available, all channels will get 50% evenly instead of environ getting 100% and equipment like, 10%. APCs would still cut out channels based on their battery percentage, which I suppose could cause some funny osclillating behavior on low-power grids. Let's see how it works out. +My current idea is that APCs distribute power to all enabled channels evenly, so if there's only 50% of required grid power available, all channels will get 50% evenly instead of environ getting 100% and equipment like, 10%. APCs would still cut out channels based on their battery percentage, which I suppose could cause some funny oscillating behavior on low-power grids. Let's see how it works out. ### Glossary for Swept @@ -139,7 +139,7 @@ Supplies will be evaluated in order of their tree height, ascending. This means This has two desirable properties: 1. If you put a generator on a local APC network, it will actually take the load off the main station grid, instead of only being able to fill in brown/blackouts. -2. It avoids upwards hierarchy walks as described below. It does not make these impossible, but it does make them basically nonexistant unless you actively go set up weird networks to trigger the behavior. +2. It avoids upwards hierarchy walks as described below. It does not make these impossible, but it does make them basically nonexistent unless you actively go set up weird networks to trigger the behavior. ### Hierarchical power distribution @@ -149,7 +149,7 @@ If operating under the assumption that power grids are a tree (not anything fanc When the power grid forms a polytree instead, we need a little bit more effort. First of all, the first tree walk is initiated by suppliers, and suppliers are iterated in the previously discussed order. It is done recursively, top-to-bottom. When a network's unmet demand gets inherited by its ancestor(s), a "reservation flag" is set on the network. If, while traversing the polytree downwards from another supplier, we come across a network that has this reservation flag set, we need to navigate the graph upwards. We navigate up the tree of reservation flags and immediately apply the met demand of supplies on the hierarchy, clearing the reservation flag along the way. Then set the reservation flag again to reserve for our own calculations. This probably requires more complex book keeping and a per-connection "power already sent" to keep track of the power that's been "immediately collapsed". Just clearing flags upwards and specifying "power already sent" on connections may be enough here. -This upwards walk is a bit of a sore spot but luckily should not happen unless you actively set up wacky networks to create it. The worst case scenario, I suppose, is setting up two long lines of networks such that they take turns taking over eachother's reservation flag and causing exponential tree walking. Maybe have a check to avoid this? +This upwards walk is a bit of a sore spot but luckily should not happen unless you actively set up wacky networks to create it. The worst case scenario, I suppose, is setting up two long lines of networks such that they take turns taking over each other's reservation flag and causing exponential tree walking. Maybe have a check to avoid this? This behavior would only happen on grids like this, which don't happen frequently on the real station: ![](https://i.imgur.com/aOquNMN.png) @@ -174,7 +174,7 @@ One idea I had is to evaluate the total current limit of the joiner network, so Basically uhhhhh if you encounter the network the second time, calculate "what is the max amount of demand that can be filled thanks to current limiting" and then take the *remaining* unmet demand for the network instead of the total. We can basically keep doing this. We *aren't* calculating power distribution here but *distribution ratios*. -The important distinction is that this grid collapse happens internally during the calculation of a single push. This means that the power grid will be internally consistent at the end and a "some nerd hooked a weighed-down supply into it randomely" and it has to collapse power distribution, it can just collapse it. The logic will be more complex however. +The important distinction is that this grid collapse happens internally during the calculation of a single push. This means that the power grid will be internally consistent at the end and a "some nerd hooked a weighed-down supply into it randomly" and it has to collapse power distribution, it can just collapse it. The logic will be more complex however. ### Distribution priorities