From f8473087f9eba7f94ca7c7705e9da6911b72d94f Mon Sep 17 00:00:00 2001 From: Kevin Zheng Date: Sun, 1 Oct 2023 11:47:49 -0700 Subject: [PATCH 01/12] Update pull request guidelines --- .../codebase-info/pull-request-guidelines.md | 93 +++++++++++-------- 1 file changed, 55 insertions(+), 38 deletions(-) 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 c41b32ee3..539bed09e 100644 --- a/src/en/general-development/codebase-info/pull-request-guidelines.md +++ b/src/en/general-development/codebase-info/pull-request-guidelines.md @@ -1,54 +1,71 @@ # Pull Request Guidelines -Following these guidelines will make contributing much easier, and will help your PRs be merged much faster by making them easy to review. - -- If you're unfamiliar with the Git workflow, please read [our git guide](../setup/git-for-the-ss14-developer.md) and ask as many questions as you need in #howdoicode. -- Do not use the GitHub web editor to make pull requests. You are required to make sure your code compiles and you've tested your changes in-game before making the PR. **PRs created through the Github web editor are liable to be closed at a maintainer's discretion, as they have not been tested locally and cannot meet these requirements.** Repeated submission of PRs made through the web editor may result in a repository ban. -- Please **re-read your code preview on GitHub** before submitting a PR. If it's obvious to a reviewer it includes your last PR (i.e. PR2 includes PR1's changes), or that there are accidental changes, then it should be obvious to you. -- If your PR adds a new feature, you should provide a screenshot or video of it functioning properly ingame. This not only makes reviewing easier, but also makes writing the progress report easier. -- Avoid adding miscellaneous additional changes to a PR, e.g. changing the heat resistance of a pair of gloves alongside your PR adding a new gun. -- Avoid making lots of formatting changes in a file if you change very few lines in it. It makes the review significantly more difficult to parse what actually changed and can generate conflicts for other PRs. -- If you do make refactoring/formatting changes, make them separate commits from actual content/feature/functionality changes so that they are easier to review. -- Large refactors that touch a lot of other systems belong in a separate refactor-only PR with no content changes -- If you move a file to a different folder and/or namespace, put that in its own commit when possible to make it easier to tell what got changed in a file and what was just moved. +Thank you for contributing to Space Station 14. When submitting pull requests (PRs), please follow these guidelines to make your pull requests easier to review and merge. Pull requests that do not follow these guidelines may be closed at a maintainer's discretion. + +## Before You Begin + +- If you're unfamiliar with the Git workflow, please read our [Git guide](../setup/git-for-the-ss14-developer.md) and ask as many questions as you need in #howdoicode. + - Please have some familiarity with [C# conventions](https://docs.microsoft.com/en-us/dotnet/csharp/) (if working with C#) and [our own conventions](./conventions.md). Try to read how other parts of the codebase are formatted for a general idea. -- Try to split your PR into smaller ones where it makes sense to do so. This makes it significantly easier to read and can lead to faster reviews. It's also usually easier for you, and means you will receive earlier feedback and can avoid spending time making changes that have to be reworked. + - Large new features and comprehensive reworks to existing large features (ie antags or anything that could be considered a subdepartment unto itself), should first be [proposed and accepted in abstract](../feature-proposals.md) before you start working on actually implementing it. -- Avoid force-pushing to your branch. This makes all reviews show as 'outdated', even if they have not been addressed yet, which makes it much harder for us. -- When you're addressing reviews, click 'Resolve conversation' on GitHub once your revised code has been pushed. -- If you have questions about reviews that were submitted on your PR (or code questions in general, of course), feel free to ask for clarification on GitHub or Discord in #howdoicode. -## Reviews +## Content + +- **Make separate PRs for feature changes, bug fixes, and cleanup/refactors.** This makes changes easier to review, reduces conflicts, and also easier to revert if something goes wrong. + + - Feature changes and bug fixes should be in their own PR. + - Cleanups and "refactoring", including variable renaming and indentation changes (for example, due to file-scoped namespacing) must be in their own PR. + - **Refactors must be in a separate PR.** This includes changes that impact a significant number of public APIs (fields, methods, etc.) that require changes across multiple systems. These must be made in a separate PR from any content changes or bug fixes. + - If you move a file to a different folder and/or namespace, put that in its own commit when possible to make it easier to tell what got changed in a file and what was just moved. + +- **Do not make multiple unrelated changes in one PR.** For example, do not make miscellaneous additional changes to a PR, e.g. changing the heat resistance of a pair of gloves alongside your PR adding a new gun. + + - Try to split your PR into smaller ones where it makes sense to do so. This makes it significantly easier to read and can lead to faster reviews. It's also usually easier for you, and means you will receive earlier feedback and can avoid spending time making changes that have to be reworked. + +## Testing + +- **Test all of your changes in-game.** All bug fixes and features must be tested in-game. You should also test other features that may be indirectly impacted by your changes. -We get around 700 PRs a month and only have a small number of active maintainers. All maintainers are volunteers and maintainer availability is very variable. Depending on the size and importance of your PR, it could take up to a few weeks before someone gets around to reviewing it. Responding to any changes may also take some time. Please be patient. + - For the above reason, **do not use the GitHub web editor to make PRs.** Web edits are liable to be closed at a maintainer's discretion. Repeated submission of PRs made through the web editor may result in a repository ban. -Anyone is welcome to review PRs. Reviews from other contributors can be just as valuable as reviews from maintainers, and often mean that PRs can be merged faster and can help relieve the worload for maintainers. If you are waiting for a review it might be a good idea to find another contributor in a similar position so that you can mutually review each other's PRs. Reading other people's PRs and thinking critically about how you would have written the code can also be a useful learning tool. +- **Provide screenshots or videos** that demonstrate testing done. This also makes it easier to write progress reports. -### Asking for reviews -Please do not simply post your PR in our discord channels without context simply to ask for reviews. However, if your PR hasn't been reviewed by anyone and it has been a month, feel free to ping those listed here on GitHub or Discord. These aren't all of our maintainers, but they're currently the most active when it comes to reviews. +## Before Submitting -**For content reviews:** -- mirrorcult#9528, @mirrorcult on GitHub -- metalgearsloth#7697, @metalgearsloth -- ElectroSR#9529, @ElectroJr -- /tmp/moony#0029, @moonheart08 +- **Review your diff** using the code preview tab on GitHub. -**For engine reviews:** -- metalgearsloth#7697, @metalgearsloth -- PJB#3005, @PJB3005 -- ElectroSR#9529, @ElectroJr -- mirrorcult#9528, @mirrorcult + - Check for changes that you did not intend to commit. + - Check for accidental whitespace additions or line end changes. -## Adding screenshots/videos to your PR -PRs which make ingame changes (adding clothing, items, new features, etc) are required to have media attached that showcase the changes or the PR will not be merged, in accordance with our PR guidelines. Small fixes/refactors are exempt. If you include media in your pull request, we may potentially use it in the SS14 progress reports, with clear credit given. +## After Submitting + +You are free to make changes to your PR after submitting, for example, if you make improvements or fix bugs that you discover after submitting. + +- **Do not force push to your branch** after receiving a review unless a maintainer requests it. Doing so makes all reviews show as 'outdated', even if they have not been addressed yet. + +# Reviews + +Reviews are an important part of the pull request process. Reviews help us obtain feedback from the community and maintain a high quality of code in the codebase. Since maintainers are volunteers, we ask for your patience. The review process for large changes can take up to several weeks. + +## Getting Reviews + +- Anyone is welcome to review PRs. Reviews from other contributors can be just as valuable as reviews from maintainers, and often mean that PRs can be merged faster and can help relieve the workload for maintainers. If you are waiting for a review it might be a good idea to find another contributor in a similar position so that you can mutually review each other's PRs. Reading other people's PRs and thinking critically about how you would have written the code can also be a useful learning tool. + +- Maintainers periodically review open PRs. + +- If it is taking several days to get an initial review, it is appropriate to ask for a review in #pr-review-request. + +## Addressing Reviews + +- When you're addressing reviews, click 'Resolve conversation' on GitHub once your revised code has been pushed. -Use screenshot software like Window's built in snipping tool, ShareX, Lightshot, or recording software like ShareX (gif), ScreenToGif, or OBS (cross platform). -If you're unsure whether your PR will require media, ask a maintainer. +- If you have questions about reviews that were submitted on your PR (or code questions in general, of course), feel free to ask for clarification on GitHub or Discord from the reviewer or in #howdoicode. -## Changelog +# Changelog Changelog entries help make players aware of new features or changes to existing features. -### Changelog Template +## Changelog Template The Github PR template contains the following changelog that you can use to format your changelog entry so that it is automatically updated in-game: ``` @@ -65,7 +82,7 @@ Each entry is either an `add`, `remove`, `tweak`, or `fix`. There can be multipl Maintainers may, at their discretion, add, modify, or remove a change log entry that you suggest. -### Writing An Effective Changelog +## Writing An Effective Changelog The Changelog is for *players* to be aware of new features and changes that could affect how they play the game. It is *not* designed for maintainers, admins, or server operators (these should be in the PR description). When writing your changelog entries, please follow these guidelines: @@ -110,4 +127,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. \ No newline at end of file + - Not so good: "Arachnids have new sprites for being creampied." *crampied* has another, unfortunate meaning that undermines the professional tone of a Changelog entry. From 4e25daa4f9b146b7c248d46adb0539fd8acf3813 Mon Sep 17 00:00:00 2001 From: Kara Date: Sun, 1 Oct 2023 12:05:38 -0700 Subject: [PATCH 02/12] Fix hub rules redirect --- book.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book.toml b/book.toml index aad926134..4e8865d84 100644 --- a/book.toml +++ b/book.toml @@ -116,4 +116,4 @@ warning-policy = "ignore" # false-positives like hell with absolute links & late "/en/engine/porting-visualizers/index.html" = "/en/ss14-by-example/making-a-sprite-dynamic/porting-appearance-visualizers.html" "/en/engine/lighting-fov/index.html" = "/en/robust-toolbox/rendering/lighting-and-fov.html" "/en/engine/sprites-icons/index.html" = "/en/robust-toolbox/rendering/sprites-and-icons.html" -"/en/hosting/hub-rules/index.html" = "/en/community/space-wizards-hub-rules.html" \ No newline at end of file +"/hosting/hub-rules/index.html" = "/en/community/space-wizards-hub-rules.html" From 2b3061e345dcc6e8e2c163d84f5962101312bdcc Mon Sep 17 00:00:00 2001 From: Andrii Nepryntsev Date: Mon, 2 Oct 2023 16:23:07 +0200 Subject: [PATCH 03/12] added 'Ukrainian' tag (#73) yeah, that's all it adds Co-authored-by: Segonist --- .github/labeler.yml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.github/labeler.yml b/.github/labeler.yml index bc8db4254..a67a088a6 100644 --- a/.github/labeler.yml +++ b/.github/labeler.yml @@ -4,5 +4,8 @@ "Russian": - 'src/ru/**' +"Ukrainian": +- 'src/ua/**' + "Scripts": - 'scripts/**' From a392e962a831c2eb6ce8b9ca7a2b45460cfafee3 Mon Sep 17 00:00:00 2001 From: Kara Date: Tue, 10 Oct 2023 17:17:21 -0700 Subject: [PATCH 04/12] Labeler for design proposals --- .github/labeler.yml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.github/labeler.yml b/.github/labeler.yml index a67a088a6..3f9346be2 100644 --- a/.github/labeler.yml +++ b/.github/labeler.yml @@ -9,3 +9,6 @@ "Scripts": - 'scripts/**' + +"Design": +- 'src/en/proposals/** From e36db6c75d4a6dbd8a77bc9a931a527c8204efbf Mon Sep 17 00:00:00 2001 From: Kara Date: Tue, 10 Oct 2023 17:17:39 -0700 Subject: [PATCH 05/12] i am literally stupid --- .github/labeler.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/labeler.yml b/.github/labeler.yml index 3f9346be2..8e7389a90 100644 --- a/.github/labeler.yml +++ b/.github/labeler.yml @@ -11,4 +11,4 @@ - 'scripts/**' "Design": -- 'src/en/proposals/** +- 'src/en/proposals/**' From c6c6fe6c3a5ec53def8da513e14ebd5f4642bed1 Mon Sep 17 00:00:00 2001 From: DrSmugleaf Date: Tue, 10 Oct 2023 17:38:25 -0700 Subject: [PATCH 06/12] Add maintainer meeting docs to the summary (#74) --- src/SUMMARY.md | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 964107986..29f4eb9cc 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -169,3 +169,40 @@ Community - [Wizards Den Admin Policy](en/community/admin/wizards-den-admin-policy.md) - [Wizards Den Banning Policy](en/community/admin/wizards-den-banning-policy.md) - [Progress Report Creation](en/community/progress-report-creation.md) + +Maintainer Meetings +============== + +---------------------- +- [2023-09-23](en/maintainer-meetings/maintainer-meeting-2023-09-23.md) +- [2023-09-02](en/maintainer-meetings/maintainer-meeting-2023-09-02.md) +- [2023-08-19](en/maintainer-meetings/maintainer-meeting-2023-08-19.md) +- [2023-07-29](en/maintainer-meetings/maintainer-meeting-2023-07-29.md) +- [2023-06-10](en/maintainer-meetings/maintainer-meeting-2023-06-10.md) +- [2023-05-20](en/maintainer-meetings/maintainer-meeting-2023-05-20.md) +- [2023-05-06](en/maintainer-meetings/maintainer-meeting-2023-05-06.md) +- [2023-03-05](en/maintainer-meetings/maintainer-meeting-2023-03-05.md) +- [2023-02-11](en/maintainer-meetings/maintainer-meeting-2023-02-11.md) +- [2023-01-21](en/maintainer-meetings/maintainer-meeting-2023-01-21.md) +- [2023-01-07](en/maintainer-meetings/maintainer-meeting-2023-01-07.md) +- [2022-07-30](en/maintainer-meetings/maintainer-meeting-2022-07-30.md) +- [2022-07-16](en/maintainer-meetings/maintainer-meeting-2022-07-16.md) +- [2022-06-25](en/maintainer-meetings/maintainer-meeting-2022-06-25.md) +- [2022-06-11](en/maintainer-meetings/maintainer-meeting-2022-06-11.md) +- [2022-05-28](en/maintainer-meetings/maintainer-meeting-2022-05-28.md) +- [2022-05-14](en/maintainer-meetings/maintainer-meeting-2022-05-14.md) +- [2022-04-30](en/maintainer-meetings/maintainer-meeting-2022-04-30.md) +- [2022-04-16](en/maintainer-meetings/maintainer-meeting-2022-04-16.md) +- [2022-04-02](en/maintainer-meetings/maintainer-meeting-2022-04-02.md) +- [2022-03-19](en/maintainer-meetings/maintainer-meeting-2022-03-19.md) +- [2022-03-05](en/maintainer-meetings/maintainer-meeting-2022-03-05.md) +- [2022-02-05](en/maintainer-meetings/maintainer-meeting-2022-02-05.md) +- [2022-01-22](en/maintainer-meetings/maintainer-meeting-2022-01-22.md) +- [2022-01-08](en/maintainer-meetings/maintainer-meeting-2022-01-08.md) +- [2021-12-11](en/maintainer-meetings/maintainer-meeting-2021-12-11.md) +- [2021-11-27](en/maintainer-meetings/maintainer-meeting-2021-11-27.md) +- [2021-11-13](en/maintainer-meetings/maintainer-meeting-2021-11-13.md) +- [2021-10-30](en/maintainer-meetings/maintainer-meeting-2021-10-30.md) +- [2021-10-16](en/maintainer-meetings/maintainer-meeting-2021-10-16.md) +- [2021-10-02](en/maintainer-meetings/maintainer-meeting-2021-10-02.md) +- [2021-09-19](en/maintainer-meetings/maintainer-meeting-2021-09-19.md) From 346282dc6a7699b8bfd6de4a9d030bd8a68aa2a3 Mon Sep 17 00:00:00 2001 From: deltanedas <39013340+deltanedas@users.noreply.github.com> Date: Thu, 12 Oct 2023 23:51:45 +0100 Subject: [PATCH 07/12] plant genetics design doc (#70) depends on botany ecs/rework design doc and could be reused with virology design doc --------- Co-authored-by: deltanedas <@deltanedas:kde.org> --- src/en/proposals/deltanedas-plant-genetics.md | 71 +++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 src/en/proposals/deltanedas-plant-genetics.md diff --git a/src/en/proposals/deltanedas-plant-genetics.md b/src/en/proposals/deltanedas-plant-genetics.md new file mode 100644 index 000000000..2bfdf8524 --- /dev/null +++ b/src/en/proposals/deltanedas-plant-genetics.md @@ -0,0 +1,71 @@ +# Feature Design: plant genetics + + + + + + + + + + + + + + +
Designer + deltanedas +
Discord/Forum Thread + TBD +
Github PR/Draft + TBD +
+ + + +# Overview: + +A new CRISPR-like machine for modifying genomes of plants. +Has a hex editor-like UI where you can seek to a position and it shows a certain number of bases. +From there you can make modifications e.g. swapping out an A at index 38 for a T. Once you are happy and think your modifications won't kill the plant, create your new seed and plant it. +Since genome layouts are randomized roundstart this would be no better than current mutagen roulette of just hoping it gets a good trait and doesnt make the plant useless. + +To solve gene roulette, the second part of this would be experimentation. +Get 2 identical seeds with clippers then mutate one a little using unstable mutagen. +Either the same machine from the start or a separate one can then analyze them and check what genes (bits) are different. +After a little bit of time it either picks a single random bit, or multiple of them, and tells the player what gene name is at that bit. If the gene has multiple bits it will take some investigation to see which bit it is but that's trivial for yield/potency which can be seen just by clipping it. +Essentially you keep experimenting on plants to figure out the index of every gene, and tada youve mapped the plant genome and can make gmos with ease for the rest of the round. + +# Goals: +Promote interdepartment stuff by requiring biomass for gene editing: +- Means there is some cost to minmaxing a plant so you might just have to settle for the important traits +- If there is no med staff / no bodies to juice you can still grow plants as normal +- There was some ideas about being able to reclaim biomass from plants so you could use that to kickstart it. +- Salvage can find biomass on expeditions as a large but irregular source, assuming med doesn't get to it first. + +# Gameplay: +The gene editing would primarily be a window like a hex editor, set a position to seek to and then itll show up to X bases. +You can modify a base by just typing A C G or T. they map to 00 01 10 and 11 respectively in binary, so for every 2 bits you get a single base. +From there the player can feed it biomass and print out a fancy new seed with a cost of say 1 biomass per bit modified. + +Unstable mutagen would randomly flip bits so you could get an increase of 8 to yield or a decrease of 1 to potency, depends on which bit it flips in an int. + +Pollen swabbing, if it still exists, would swap entire gene values rather than operate on a random bit basis. + +This might have botanists split up between growing plants for chef and focusing on mapping the genome to get gamer seeds which is cool. + +Additionally, instead of the current mutation of a viable bool, a system would be in place where there are bits that set unreasonable pressure temperature or light requirements to grow. +If a plant suddenly requires being grown in space or a fire you are unlikely to try, but it's still possible if you are extremely determined. + +# Components: +Plant entities would both have GenomeComponent and its own component for handling swabbing/crossbreeding along with copying genes from parent when clipping. + +Since only bools and ints can be stored in genomes, chemicals would still need to be in solution container component and mutated manually similar to how its done currently with SeedData chemicals. + +# Inspirations: + +- life + +# Requirements: + +Depends on a rework of botany to have plants be ECS. From 66e39b133f62d824574240f16a954225187030f4 Mon Sep 17 00:00:00 2001 From: Kara Date: Fri, 13 Oct 2023 20:32:35 -0700 Subject: [PATCH 08/12] Anomaly cores & the GORILLA gauntlets (#77) from a discussion in #development and from my own mind. not super inspired by the TG anomaly cores, these are basically unrelated concepts but i will be using their sprites --- src/en/proposals/anomaly-cores.md | 45 +++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 src/en/proposals/anomaly-cores.md diff --git a/src/en/proposals/anomaly-cores.md b/src/en/proposals/anomaly-cores.md new file mode 100644 index 000000000..3fec4552e --- /dev/null +++ b/src/en/proposals/anomaly-cores.md @@ -0,0 +1,45 @@ +# Anomaly Cores and the G.O.R.I.L.L.A Gauntlets + +The intention of this proposal is not to expand the anomaly gameplay system through breadth (i.e. more stuff) but to add new dimensions of gameplay and new incentives entirely. This will be done through two main additions: **inert & decaying anomaly cores**, and the **G.O.R.I.L.L.A Gauntlets**. + +## Anomaly Cores + + + +**Anomaly cores** are generated when an anomaly dissipates in some way. An *inert* core is spawned when an anomaly is fully contained and fizzles out, and a *decaying* core is spawned when an anomaly goes supercritical. + +Inert cores are functionally useless on their own, sell for a small amount of money, and glow faintly. They become useful in conjunction with the G.O.R.I.L.L.A, which will be elaborated on later. They can also be made into anomaly core pie! + +**Decaying cores** are the interesting ones. When an anomaly goes supercritical, it will spawn a decaying anomaly core of the same type as the anomaly. These cores can be sold for a large sum of money, converted into a fairly high amount of research points, or *used by anyone for a one-time anomaly-specific benefit* (this use will not be included in the initial PR for scope reasons). + +Over time, decaying anomaly cores will slowly *lose their value* and eventually convert into an inert anomaly core. If it isn't sold, exchanged, or used fast, then the whole endeavor could prove pointless. + +### Intended Gameplay + +The point of decaying anomaly cores being generated is twofold: First, it provides a potential benefit for anomalies which accidentally go supercritical or are untended to. Second, it gives anomalists the interesting choice to **intentionally make an anomaly go supercritical** for huge rewards, if they feel that they're capable of handling the aftermath. + +Decaying anomaly cores being time-limited is very important. This introduces more gameplay by forcing people to take some risks to extract as much value as possible. For instance, you might just run into a supercritted gravitational anomaly to take its core even if you risk harming yourself. It also forces the decision of *how* to use the anomaly core quickly, which can lead to some fun social scenarios. + +## The G.O.R.I.L.L.A Gauntlets + +```admonish info +or, Gauntlets Orchestrating Relocation of Interloping and Ludicrously Livid Anomalies +``` + + + +The G.O.R.I.L.L.A Gauntlets are an item obtainable through Tier 2 experimental research (subject to change). It functions as a set of wieldable power fists that can deal strong brute damage. However, they're not very strong on their own. To take full effect, they need to be **with an anomaly core**. + +When the gauntlets are loaded with either type of anomaly core, they gain the ability to force throw anything they hit backwards, until it hits a wall. **This includes anomalies, and thus the gauntlets function as a method of moving anomalies.** Inert cores only give you five charges to work with (subject to change), while decaying cores will work until they run out, and deal significantly more damage. + +Anomalies which are hit with the gauntlets will take some minor stability damage. Anomalies in the process of going supercritical can also be hit with the gauntlets. Because of the nature of how the force throw works and the limited charges of an inert core, anomalists will have to first consider the most efficient path and set of pushes to get the anomaly in a more useful location. + +### Intended Gameplay + +The G.O.R.I.L.L.A gauntlets open up many more choices for anomalists. Before, if an anomaly spawned in a particularly unfavorable spot (such as medbay), science was heavily pressured to contain and decay it entirely rather than trying to exploit it, and for good reason. People have often asked for a way to move anomalies, but of course, anomalies' locations being random is a huge part of what makes them interesting to contain. + +With the G.O.R.I.L.L.A gauntlets, anomalists have a way to move unwieldy anomalies in an interesting way that generates rather than removes gameplay: +- The gauntlets require an inert core and research, so science must already have invested some time into anomalies already +- The inert cores have finite charges, so science cannot always rely on them +- The movement of the anomaly is not as simple as 'point A to point B', and because of the limited charges, scientists must consider the location of the anomaly and where they'll be able to move it within 5 pushes, kind of like a box-pushing game or a Pokemon ice tile puzzle, which is a fun mini-challenge on its own. +- Expert anomalists will be able to modify the environment to get anomalies in even more favorable locations and they will likely have to coordinate with others to move it through doors, hallways, into smaller rooms, etc, introducing a new degree skill expression, on top of knowing when to make the decision to try and move one rather than contain or harness it. \ No newline at end of file From 53ec2d43b5879ea9dab10dbfc289ef00a17da7ac Mon Sep 17 00:00:00 2001 From: Albert Snow Date: Mon, 16 Oct 2023 19:36:46 -0500 Subject: [PATCH 09/12] Update setting-up-a-development-environment.md (#81) --- .../setup/setting-up-a-development-environment.md | 5 +++++ 1 file changed, 5 insertions(+) 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 b618c8bb4..0ea9a92f9 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 @@ -132,3 +132,8 @@ Unhandled exception. Robust.Shared.IoC.Exceptions.ImplementationConstructorExcep ``` Uninstall .NET Core SDK x86. Install .NET Core SDK x64. + + +## The client and server aren't available in Visual Studio to configure in Multiple startup projects + +This may be because you opened the project as a folder rather than a solution. Make sure you open it as a solution and click the space station 14 .sln file. From b4c37f29b80158199374b209881b9bbf1d451e8b Mon Sep 17 00:00:00 2001 From: DrSmugleaf Date: Tue, 17 Oct 2023 17:44:38 -0700 Subject: [PATCH 10/12] Add missing September 9th maintainer meeting notes (#84) --- src/SUMMARY.md | 1 + .../maintainer-meeting-2023-09-09.md | 122 ++++++++++++++++++ 2 files changed, 123 insertions(+) create mode 100644 src/en/maintainer-meetings/maintainer-meeting-2023-09-09.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 29f4eb9cc..e75d8b3f3 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -175,6 +175,7 @@ Maintainer Meetings ---------------------- - [2023-09-23](en/maintainer-meetings/maintainer-meeting-2023-09-23.md) +- [2023-09-09](en/maintainer-meetings/maintainer-meeting-2023-09-09.md) - [2023-09-02](en/maintainer-meetings/maintainer-meeting-2023-09-02.md) - [2023-08-19](en/maintainer-meetings/maintainer-meeting-2023-08-19.md) - [2023-07-29](en/maintainer-meetings/maintainer-meeting-2023-07-29.md) diff --git a/src/en/maintainer-meetings/maintainer-meeting-2023-09-09.md b/src/en/maintainer-meetings/maintainer-meeting-2023-09-09.md new file mode 100644 index 000000000..6a543c882 --- /dev/null +++ b/src/en/maintainer-meetings/maintainer-meeting-2023-09-09.md @@ -0,0 +1,122 @@ +# Maintainer Meeting (09 Sep 2023) +```admonish info +Any decisions taken in these notes may no longer be applicable. +``` + +**Time:** 09 Sep 2023 18:00 UTC + +**Attendees:** +- ElectroSR +- ShadowCommander +- Sloth +- PJB +- DrSmugleaf +- Notafet +- Julian +- Visne +- faint +- TheQuietOne +- keronshb +- Lank + +## Remove component lifestage properties | metalgearsloth +- Remove component lifestage properties (this is a long-term thing but mainly looking at stopping new code adding checks): +- 90% of the time it's a bandaid for other shitty code +- probably needs removing when we go to struct components in the distant future +- Can probably just check the entity lifestage in most bandaid cases instead anyway +- **Fund it** +- **Most component stuff can just check entity instead, not too hard to remove** +- **Removing entity life stage would be much harder** + +## Remove Component.Deleted | metalgearsloth +- adds unnecessary overhead to some codepaths like TryGetComponent\ / HasComponent\ +- It's really only useful in cases where something is queued but not removed yet but even then I'm kinda suss +- we can probably start investigating after arch port is stable +- **Do it** +- **How are we delaying component changes to the end of the tick some day who knows** + +## Use the pooled collections instead of List\ / HashSet\ etc | metalgearsloth +- Uses the ArrayPool to back the arrays +- Should reduce heap allocsTM +- https://github.com/jtmueller/Collections.Pooled +- we may need to import it anyway for arch +- **Yes in engine, to replace ObjectPool** +- **Don't sandbox Shared pools** +- **Pool objects shouldn't be returned by methods** +- **I don't like it because it makes spaghetti out of memory management, and is basically just a bad bandaid after you give up doing it properly™️** - PJB + +## Arch and performance | metalgearsloth +- We should get AddComp etc to have content start leveraging minimising archetype changes though not sure how we want to handle it. +- any other overloads we could think of + - HasComp, RemoveComp, TryGetComp, EnsureComp +- how do we handle queries i.e. does content cache our existing queries, how do we handle not having .WithAll\ / .WithAny\ / .WithNone\, do we cache arch queries and just have engine relay them, idk) + - **Use query description in engine** + - **If used from content, validate the types that the query handler asks for as Arch doesn't check (it just crashes)** + +## NetEntities and handling unknown entities to the client | metalgearsloth +- NetEntities and handling unknown entities to the client: client may get netentity for something it might not know about yet (due to streaming or whatever else). How do we handle this and what's going to be the best way 3 years from now, e.g. some kind of handle for netentity + entity and entitymanager just updates the field when it comes in? +- Right now client just leaves the entityuid and code just checks for trygetcomp / deleted and it will just suddenly work when the entity comes in but with the entityuids no longer matching (and the entity may not exist yet) this is no longer possible +- Like: +- Do networked comps just store NetEntity? This is kinda ugly and adds dictionary overhead to everything +- Do we somehow put a ref on entitymanager then update it when the gamestate comes in and the entityuid automagically updates? +- **https://discord.com/channels/310555209753690112/900426319433728030/1147795695286362112** + +## Refactoring UpdateBoundStateMessage / whatever the fuck UI is doing to compstates | metalgearsloth +- do we just dump all the data on components +- any data not already comps just dump on a dedicated UI component? +- **"You can scroll two points down for the BUI entities topic"** + +## Changing TryComp\(out var comp) to TryComp(out T comp) for most usages | metalgearsloth +- We had this discussion a long-ass time ago, like 4 years ago +- the latter is shorter +- I preferred it but we ended up using the former +- I think performance is almost identical +- bottom text +- **If we enforce it, enforce it with an analyzer** + +## BUI entities | PJB +- Opening BUI just creates an entity that handles the UI logic. UI data is in that entity's components. We can do composition for various types of behaviors like interaction range. Move it all to content. PVS filter it so only target player has vision over it. One entity per BUI session (player). +- Do we give a shit about optimizing UI states if two players view the same UI? Right now this allows re-using the data but it seems like such a minor thing it's not worth making the system more complex over +- gooey booey looey +- **When you code it, ez clap, we're all in agreement** + +## Disallow using Math and MathF | moony +- and make people use the type-specific functions instead that .NET 7 added +- so for example Math.Pow(x, y) would be double.Pow(x, y) +- Math/MathF are only defined for a limited set of types and are overall a bit more "magical" for what types they allow (due to overloading), so being explicit about the type is cleaner and allows that implied API to be extended (MyNumberType.Pow(x, y) would be what you'd expect to exist instead of initially guessing Math.Pow(x, y)) +- all the functions on Math/MathF have equivalents on the type being operated on for the C# builtin types +- including the constants, so for example float.Pi exists +- also the divide between MathF and Math is just plain confusing most of the time +- **When you write an analyzer for it, for engine only** + +## *"the thrilling case of the missing documentation "* | mirrorcult +- ok can we admit “just ask us for access to edit the dev wiki” is a failed prospect. no one actually knows you can do that and if they do know they dont want to bother with the friction of finding out who to ask and waiting just to submit a fix. as a result the dev wiki is extremely atrophied +- oh my god PLEASE can we move it all to mediawiki or something, i dont care what it is wikijs was a bad idea and i just want something that anyone can edit and add articles to. please +- we really desperately need to do a full audit over the docs, not necessarily like add new stuff rn because i get thats effort but just make sure its up to date information and all useful pages are actually discoverable +- maybe think about mirroring codebase changes to docs site once we get something better like mediawiki. this would probably involve just linking to the docs page in GH and discord as the source of truth +- we REALLY need to make the docfx sites more visible and linked in more places (and docs in general but), discord channels/pins/github/forum/ingame literally everywhere please (and maybe give them better domain names theyre really bad rn) and also + - add a ‘component glossary’ section to docfx which just shows all types that are registered components and what docs/fields they have. like half of the people in <#560845886263918612> ask for something like this and we just have to tell them ‘uhhh look in your IDE’ which is good when they already have the component they're looking for but terrible for when theyre trying to discover potential components they can use for some behavior + - topy was working on this at some point but they are inactive now. if possible just revive their branch we really need this +- **When You Document It** +- **We'll host it for whoever wants to experiment with shit** +- **I saw the search bar on mdbook and I'm convinced** +- **Replace wikijs with mdbook** + +## Early Access Roadmap +- **nothing on this roadmap matters except early access trailer.** +- A trailer for Steam + - Also the >>>>**screenshots**<<<< for steam and the website + - holy shit we have **replays** now +- gamemodes/antags + - dynamic [c#16548](https://github.com/space-wizards/space-station-14/pull/16548) + - revolutionaries [c#18477](https://github.com/space-wizards/space-station-14/pull/18477) + - wizard +- The game runs like shit how do people play this + - "IDK but maybe when I fix the watchdog you can figure it out easier" | 09/09/2023 + + +Crashes / Critical bugs: (when are we moving these to GitHub) +=> till next time +like and subscribe +smash that button +~~did you know only 6% of contribs join this meeting?~~ According to YouTube's statistics, From 318ea595cf621cabeb43882504251edbf6b888f4 Mon Sep 17 00:00:00 2001 From: DrSmugleaf Date: Thu, 19 Oct 2023 12:41:31 -0700 Subject: [PATCH 11/12] Update conventions.md for Entity --- .../general-development/codebase-info/conventions.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/en/general-development/codebase-info/conventions.md b/src/en/general-development/codebase-info/conventions.md index fd2e14906..8dc514cc6 100644 --- a/src/en/general-development/codebase-info/conventions.md +++ b/src/en/general-development/codebase-info/conventions.md @@ -316,10 +316,10 @@ Transform(uid).Coordinates; ### Public API Method Signature All public Entity System API Methods that deal with entities and game logic should *always* follow a very specific structure. -All relevant `EntityUid` should come first. +All relevant `Entity` and `EntityUid` should come first. +The `T?` in `Entity` stands for the component type you need from the entity. +The question mark `?` must be present at the end to mark the component type as nullable. Next, any arguments you want should come afterwards. -And finally, all the components you need from the entity or entities should come last. -The component arguments shall be nullable, and default to `null`. The first thing you should do in your method's body should then be calling `Resolve` for the entity UID and components. @@ -327,11 +327,11 @@ The first thing you should do in your method's body should then be calling `Reso Example (click to expand) ```csharp= -public void SetCount(EntityUid uid, int count, StackComponent? stack = null) +public void SetCount(Entity stack, int count) { - // This call below will set "stack" to the correct instance if it's null. + // This call below will set "Comp" to the correct instance if it's null. // If all components were resolved to an instance or were non-null, it returns true. - if(!Resolve(uid, ref stack)) + if(!Resolve(stack, ref stack.Comp)) return; // If the component wasn't found, this will log an error by default. // Logic here! From 4c8b90d60d93192c5e9459856039e6024603cb71 Mon Sep 17 00:00:00 2001 From: Vasilis Date: Fri, 20 Oct 2023 05:54:35 +0200 Subject: [PATCH 12/12] Make runthis.py troubleshooting a bit more friendly (#80) --- .../setup/setting-up-a-development-environment.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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 0ea9a92f9..717ae7c75 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 @@ -25,9 +25,9 @@ If you're **unfamiliar with Git**, or just don't know how to proceed, follow the We have an automatic submodule updater so you don't have to worry about running `git submodule update --init --recursive` all the time. -Run `RUN_THIS.py` inside the repo you downloaded with Python. Preferably from a terminal too. This should take a few seconds so if it instantly stops you probably aren't using Python 3.7+ or something. Try checking out the troubleshooting at the bottom of this page. +Run `RUN_THIS.py` inside the repo you downloaded with Python. Preferably from a terminal too. This should take a few seconds so if it instantly stops then check if you are running Python 3.7+ otherwise keep reading. -**If running `RUN_THIS.py` immediately opens and closes a window: do not worry.** This does not mean that it failed. The script closes automatically upon completion, so if you want to verify that it worked properly, check the submodule `/RobustToolbox/` and verify that all the files are there. +**If running `RUN_THIS.py` immediately opens and closes a window: do not worry.** This does not mean that it failed. The script closes automatically upon completion, so if you want to verify that it worked properly, check the submodule `/RobustToolbox/` and verify that all the files are there. If not try checking out the troubleshooting at the bottom of this page. Note: If you have any issues when getting started with missing files it's recommended you run `git submodule update --init --recursive` by hand once in case something went wrong with python.