mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-08-25 22:19:30 +01:00
docker-container
109
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 BloopandGitHub
|
e6e0200edb | Makes quirk points configs get loaded into vars on the subsystem, + a small biome fix (#95941) | ||
|
|
aa4dc56835 |
Removes Station-time (more time changes) (#95744)
## About The Pull Request Removes Station-Time entirely Server Time is now NST (Nanotrasen Standard Time). SS13 takes place exactly 540 years in the future of the current day, so every second is 1 second in-game. Round Time is now PT (Pay-Time), how Nanotrasen keeps track of how long the current rotation of Employees has been working for. Telecomms uses NST due to its importance of being the communication to the blackbox. Autopsy report, clocks, scientific reports and requisitions use both timestamps due to them being more official documents that NT may need to know beyond just the current round (just for flavortext). Pretty much everything else (Det scanner, PDA, IC logs, Time-of-Death, AI law changes, Cyborg file downloading) uses PT PT <img width="305" height="217" alt="image" src="https://github.com/user-attachments/assets/cef73025-6292-4f9c-8565-197397bda2ca" /> <img width="168" height="59" alt="image" src="https://github.com/user-attachments/assets/a99db568-045d-45fc-8206-0d9a7b13c7d2" /> <img width="308" height="122" alt="image" src="https://github.com/user-attachments/assets/37ca6f17-8916-4af2-9c91-0f0707038ca5" /> https://github.com/user-attachments/assets/29445051-c98b-4af3-a657-812083aab91a Clock (Literate) <img width="748" height="292" alt="image" src="https://github.com/user-attachments/assets/c824e812-91b5-4737-858d-768336e9a7c4" /> Clock (Illiterate) <img width="446" height="94" alt="image" src="https://github.com/user-attachments/assets/90d5ea0d-eaff-4ced-aa31-ffdf0b4832a5" /> New paperwork time working properly <img width="311" height="190" alt="image" src="https://github.com/user-attachments/assets/6d048926-db61-4c91-893b-ce93e1ea7775" /> NST <img width="800" height="115" alt="image" src="https://github.com/user-attachments/assets/35ffde49-13c1-4ce7-ab24-858e48b608bd" /> <img width="1288" height="142" alt="image" src="https://github.com/user-attachments/assets/40c30d16-e0de-4efc-b460-9486eeb901d6" /> # Other changes 1. Circuit time checker will now get the value of the given input (Hour, Minute, Second) rather than the full dedisecond time converted into hour/minutes/seconds <img width="270" height="67" alt="image" src="https://github.com/user-attachments/assets/097440cc-1c45-447f-9976-18de7f9c722c" /> 2. Turns nightshift into a round event that'll last approximately 22 minutes 3. 12-hour pref (doesn't apply to the stat panel because it's global info) & removal of "TCT" time <img width="569" height="440" alt="image" src="https://github.com/user-attachments/assets/d39083b1-d248-41c0-9a1c-b2398ca203a7" /> 4. The chocolate pudding negative moodlet is now based on the server's IRL time. 5. Admins can now use ``class``, ``style`` and ``background`` (they were already given perms to use ``img`` so hiding background, which was removed to prevent image embedding, is pointless) 6. Also fixes ``year`` being off on localhost. ## Why It's Good For The Game Server Time is approximately 1s = 12s converted, not including it desyncing from lag (I believe?). This makes it pretty much impossible for people to actually use this as a unit of measurement for in-game actions. Different things also uses different timestamps which is a bit more confusing. The main change here is for accessibility and, hopefully, using time as a source of immersion. "20 minutes ago" is no longer OOC, they're just speaking in PT. There's no timezones in space, Nanotrasen Standard Time is the closest there is, but Pay Time is how NT considers when you get your paychecks, so it's what is more commonly used. It also fixes major inconsistencies between "IC time" and "Station time", things like breakfast moodlet was the first 15mins of the round despite the round starting like 7 hours in? Nukies with an L6 SAW firing down the halls was shooting like 1 bullet every 3 seconds (assuming 4 bullets per second), overall there was just a disconnect between how long time actually is in the universe. The secondary reason for this change (though it is what pushed me to actually get around to making this change) is the greater stat-panel removal. This hopes to lessen the dependence on the stat panel for station-time by making it easier to understand, and the end-goal I have is for this information to be limited to Admins & the AI (AI will get the IC version with the accurate year), so until that happens I would like to improve the use of station-time by making it consistent (for example, you should only care for PT for IC, which is also what your PDA displays), so that when it gets removed it won't leave players timeless. If you haven't already, and is interested in helping remove the stat panel, every entry that needs to be removed can be found here - https://hackmd.io/443_dE5lRWeEAp9bjGcKYw?view Closes https://github.com/tgstation/tgstation/issues/94988 ## Changelog 🆑 del: Removed Station Time, now we use NST (Nanotrasen Standard Time), which is IRL server time +540 years, and PT (Pay Time), the amount of time since the round has started. del: Station nightshift is now a Station event rather than being based on Server time. balance: Time circuit's Unit of Measure now tells the amount of time in hour/minute/seconds rather than giving the whole time translated to hours/minutes/seconds. qol: Added a 12-hour clock pref for people who prefer it. qol: Hovering over NST timestamps on official documents will now translate how much it is in PT/Shift Time. admin: Admins can now use style/class/background in their papercode. /🆑 --------- Co-authored-by: Isratosh <Isratosh@hotmail.com> |
||
|
LemonInTheDarkandGitHub
|
185a04a767 |
Implements configurable policy.json paths, so admins can better implement per server policy (#95620)
## About The Pull Request Headmins were having trouble with per server policy (due to changes in how their config is structured), this lets them repath policy.json, so they can override it to a per server config (see the structure seen in https://github.com/tgstation-operations/server-config) Moved heretic ascension config into game_options, cause I think that's what it is. ## Why It's Good For The Game Mei asked me for this, headmins should be able to headmin |
||
|
MrMelbertandGitHub
|
e9d964789b |
Swags out the roundstart report (#95149)
## About The Pull Request The roundstart report has been dripped out with a logo and some additional flavor <img width="585" height="916" alt="image" src="https://github.com/user-attachments/assets/d0dab027-24e4-4d4a-a5ad-59616b3bf33d" /> The flavor messages are just some randomly selected lore tidbits or filler text Other changes: - Paper now updates to your writing implement immediately, rather than on process ticks. - Adds a config to hide the dynamic report for cutting down the length of the roundstart report. Disabled by default - Footnotes now requires `R_FUN` rather than `R_ADMIN` ## Why It's Good For The Game Makes the command report look a ton more official while introducing some fun worldbuilding. ## Changelog 🆑 Melbert qol: Paper UI now updates immediately when you pick up or drop a writing tool. qol: The roundstart command report has had its style updated, and now contains some bonus lore. admin: Changes the perms needed to add command report footnotes to "Fun" rather than "Admin" admin: Adds a verb for changing the command report main contents (Requiring "Fun") config: Adds a config for hiding the dynamic report, disabled by default (disabled meaning you still get the report) /🆑 |
||
|
|
3ea7b03369 |
Accentuate the positive with **Personality**: A (soft) mood rework (#92941)
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> |
||
|
MrMelbertandGitHub
|
c8647bdf6c |
Adds config for roundstart blue alert (#92015)
## About The Pull Request Adds a config option `roundstart_blue_alert` which determines if the station is put on blue alert on roundstart. **Greenshifts** are unaffected, they will still have a unique announcement indicating it's a greenshift **Roundstart reports** are unaffected, they will be sent regardless. ## Why It's Good For The Game Some servers put more player agency on command to control the report level, some servers re-theme the levels so blue is more of an involved thing, some servers put more weight on the current level, etc. Giving the option of staying on green until someone decides to up it is neat I guess. Before doing this I tried to find when this was even added - to see what the justification was and make sure I wasn't violating it - and wasn't successful. R4407 had "`Security Level Elevated`" in their reports but didn't have security levels implemented, so it was purely fluff. ## Changelog 🆑 Melbert config: Adds "roundstart_blue_alert", allowing you to disable roundstart blue alert. Defaults to "on". /🆑 |
||
|
|
1c540bd546 |
Configurable events (removes mult config) (#90659)
## About The Pull Request As said in https://forums.tgstation13.org/viewtopic.php?t=38517 - Admins don't want to touch the event multiplier configs because, ``for example changing the mult to 1.5 would make heart attack only roll on 60+ pop`` and ends with; ``it would be better to make a pull request to the codebase and alter the min_player var on the events that are issues`` So why not let ALL events be editable by admins? This PR makes every single event possible to be edited, though the json only comes with the non-wizard non-holiday ones (though they are totally addable if admins want to put it in, I just didnt think we should make it obvious it's possible so they DONT) The config is off by default (no effect regardless since I have it the same as code-side). ## Why It's Good For The Game The multiplier config is rendered irrelevant by instead being able to tweak the individual events to your liking, especially when one touch of that causes certain events to be rendered never runnable. This is (sorta) an admin request, and it also makes event rarities and such an admin issue, therefore not our problem anymore (mostly), wahoo. Get FUCKED, Grid Check!  ## Changelog 🆑 config: Removed event time/weight multipliers, now all events vars are editable in config. /🆑 --------- Co-authored-by: CRITAWAKETS <sebastienracicot@hotmail.com> |
||
|
Jordan DominionandGitHub
|
f776000677 |
Prevent admins from using restart option which can leak DB connections. Adds timeouts to TTS HTTPS requests (rust-g version bump required). (#90182)
🆑 config: Added `TTS_HTTP_TIMEOUT_SECONDS` for setting the maximum duration TTS HTTP requests can run for before being aborted. /🆑 DNM because we need the rust-g PR to get released: https://github.com/tgstation/rust-g/pull/210 Crit prio because rounds will not restart if there are hung TTS requests and the TTS server is absolute dogshit and doesn't prevent them. |
||
|
|
cbc3350224 |
Custom Shuttles Redux: Allows for the construction of custom shuttles. (#88493)
## About The Pull Request This incredibly detailed PR adds the ability to construct custom shuttles, which function similarly to whiteships. To construct a custom shuttle, you need the following items: - Shuttle frame rods These rods can be hand-crafted by using 5 rods on 1 sheet of titanium, or printed at a sci/engi/cargo lathe after researching the Shuttle Engineering techweb node. Lattices built with these rods, and catwalks/floors built on top of these lattices, are valid for shuttle construction. - Shuttle engines Did you know shuttle engines have boards that weren't normally obtainable? Well the board for one specific engine type is now available from the sci/engi/cargo lathe after researching Shuttle Engineering. Of course, the old options remain. You can steal engines from other shuttles, including escape pods (it's not like engines are strictly necessary for *those* shuttles anyways). Alternatively, the shuttle engine supply pack is no longer locked behind the purchase of the BYOS. - Flight Control & Navigation Console boards These boards are printed at the sci/engi/cargo lathe after researching the Shuttle Engineering techweb node. If built on a custom shuttle, it will automatically link to it, unless the shuttle already has such a console. If built on a turf that is valid for custom shuttle construction, it will automatically link to any shuttle constructed from or expanded with that turf. - Shuttle blueprints Standard shuttle blueprints can be printed at the sci/engi/cargo lathe after researching the Shuttle Engineering techweb node. A cyborg upgrade granting access to a shuttle blueprint database can be printed at the exofab after researching the aforementioned node. Crude shuttle blueprints can be crafted by hand with a sheet of paper and either a rainbow crayon or 10 uses of a blue crayon or spraycan. If Science won't research the tech, you can also buy a goody pack containing a flight control board, a docker board, two engine boards, and a set of shuttle blueprints for 1200 credits, if you have aux base access. A shuttle can be constructed atop any continuous region of turfs containing a shuttle rod lattice or a catwalk/tile built upon such. Currently, this region cannot intersect any area other than space, lavaland, the icemoon, or the station asteroid. Preexisting custom areas can be included in the construction of the shuttle, but only if every turf in the custom area is valid for shuttle construction. In the shuttle blueprint UI, you can toggle a visualizer to display which turfs fulfill all of the aforementioned conditions. The following video goes through the basic process of shuttle construction. https://github.com/user-attachments/assets/3283422e-a201-4978-972d-67527b5df4ee The blueprint used to construct the shuttle will be its master blueprint. The master blueprint can be copied to other blank shuttle blueprints (or to engiborgs with the shuttle database upgrade), and allows the holder to perform a christening ritual on the shuttle to rename it. If a shuttle's master blueprint ceases to exist, a blank blueprint can be linked to the shuttle to become the new master blueprint, or an existing blueprint associated with that shuttle can be promoted to the master blueprint. Once constructed, the following options are available from the blueprint UI to modify it: - Create Area Convert a continuous open area of the shuttle into a new area with the name written in the above text input. This operates very similarly to regular area construction. - Rename Area Change the name of the area you're currently in to the name written in the above text input. - Expand Area Add a continuous open area of the shuttle to the neighboring area selected from the dropdown to the left. This operates like regular area expansion. - Expand Shuttle Expand a shuttle with valid frame turfs as defined above. These turfs must be physically connected to the shuttle. - Remove Area Remove an area, giving its tiles to the default shuttle area. - Cleanup Empty Space (implemented after the above video was recorded) Removes all completely empty turfs from the shuttle. If all the turfs in one of the shuttle's areas were removed, that area is deleted. If absolutely no turfs of the shuttle remain, the shuttle itself is deleted. Due to the ability for this action to delete the shuttle, only the master blueprint can do it. As mentioned above, the shuttle's master blueprint can be used to christen its associated shuttle. To do this, fill a glass drink bottle with some amount of reagents, then hit it against one of the shuttle's walls from outside while holding the master blueprint. You will be prompted to enter a new name for the shuttle. The variety of things that can happen while inputting a new name can cause the christening rite to fail in one of several humorous ways. ### Optional (Unless specifically requested by a maintainer) Todo's - [x] A way for shuttle circuits to be obtainable without techweb nodes - [x] A more convenient way to carry around shuttle engines or the means to deploy them - [ ] A shuttle construction guide available as a reference book - [ ] Allow boards to be linked to shuttles before construction so they can be used outside the shuttle ## Why It's Good For The Game Shuttles have been part of the sandbox for an incredibly long time, but their limited accessibility has rendered them the exclusive territory of lucky space explorers or the few antagonists who get one off the bat (nukies and pirates). Giving players the means to construct shuttles to their liking opens up a variety of possibilities for gimmicks for antags and non-antags alike. Besides the applications for antaggery and crew-sided gimmicks, this provides side content for several departments to engage with during the relatively-frequent periods of time where they have little else to do as part of their intended roles. With respect to engineering, if the station isn't actively being damaged, the supermatter is in perfect working order, and nobody is clamoring for machine upgrades, engineers have little else to resort to other than construction projects. While the BSA station goal provides an incentive for engineers to construct dedicated rooms for the cannon, it will not necessarily be available every round. Custom shuttles not only provide such a construction project to pursue, but provide the rare opportunity, as well as a very good reason, to set up an independent power network, complete with its own power source. While atmos techs have a lot to do with gas mixing and the crystallizer, they rarely get the opportunity to set up working life support systems outside of repairing the ones that get blown up. Custom shuttles will frequently start with no air, and unless the design settled upon is an open floor plan, it will have several independent chambers that cannot so easily be profused with a proper airmix by just opening a canister. Furthermore, if the air in a custom shuttle gets messed up, a proper scrubber and distro network is a significantly less tedious method of rectifying the problem than cleaning the air manually with portable scrubbers and pumps. Scientists, it can be argued, with their access to RPDs through ordnance, have similar opportunities to atmos techs, even though the act in and of itself is not exactly part of their duties. But compared to the other job content they could be working with after they've completed most of their gameplay loop, custom shuttle construction is a substantially more active endeavor. And I know how much people complain about late-game science content just being sitting around at a console and making gamer gear. Roboticists can have a part to play in this too. They can put their mech RCDs to a use other than 2D topdown Fortnite, and with the shuttle database upgrade, they can help interested cyborgs get in on the action. Cargo is yet another department known for having significant amounts of downtime during a considerable number of rounds. If every other department has gone through their initial rounds of departmental orders, and there isn't an active need for cargo to order lots of one thing or another, cargo techs have little to do besides mail (at least on the days where there **is** mail to deliver). Usually, if cargo techs do, in fact, do something as a department when not presented with more pressing duties, they order guns and other contraband. As funny as this is, there's not a lot of variety in how this behavior manifests. With custom shuttles, cargo can use their free time to plan, and execute, a unique collective expression of design sensibilities, not limited by the size and shape constraints of the cargo bay itself. ## Changelog 🆑 Y0SH1_M4S73R (with special thanks to Vect0r, whose original PR inspired the implementation of these changes) add: Shuttle blueprints, the tool used to construct and modify custom shuttles. Print a set at a science, engineering, or cargo techfab after researching Shuttle Engineering, or craft a crude set from the crafting menu. add: Shuttle blueprint database upgrade for engineering cyborgs, printable from the Exosuit Fabricator after researching Shuttle Engineering. A version of shuttle blueprints designed for use by cyborgs. add: Shuttle frame rods, usable to construct custom shuttles. Hand-craft by using 5 rods on 1 titanium sheet, or by printing them at a science, engineering, or cargo techfab after researching Shuttle Engineering. add: Custom shuttle flight control and navigation boards, printable from a science, engineering, or cargo techfab after researching Shuttle Engineering. add: Shuttle engine boards can be printed from a science, engineering, or cargo techfab after researching shuttle engineering. add: The shuttle engine supply pack is no longer locked behind the purchase of the Build Your Own Shuttle kit. add: Shuttle Construction Starter Kit goodie pack, containing a set of shuttle blueprints, flight control and navigation console boards, and two engine boards, can be purchased from cargo for 1200 credits. Requires aux base access to purchase. refactor: Shuttles now keep track of what areas are underneath each of their individual turfs, so that the areas left behind on movement are consistent with what they were beforehand. refactor: Shuttle ceilings now place themselves down as baseturfs, instead of only appearing if the turf above is open space. /🆑 --------- Co-authored-by: vect0r <71346830+Vect0r2@users.noreply.github.com> Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com> Co-authored-by: necromanceranne <40847847+necromanceranne@users.noreply.github.com> |
||
|
JacquerelandGitHub
|
8c6062e948 |
Traitor Reputation does not scale with population & reintroduces population locked items (#89617)
## About The Pull Request Closes #89617 Prior to progression traitor some items were only available with a minimum number of (normally 25) players in the round. These items were: - The dual esword - Noslip shoes - The ebow - Holoparasite - Sleeping Carp - Contractor Kit - Maybe a couple of others that I forgot to write down When we moved to a progression system this concept was merged with reputation; under 20 players your reputation would advance more slowly thus making these "dangerous" items less obtainable and also serving as a sort of scaling factor on rewards (with fewer players the secondary objectives are easier to complete, so the reward is commesurately lower). Now that we have removed secondary objectives this doesn't really make sense any more, so now reputation simply advances at a rate of one second per second all the time, but that leaves the old population locks in question. So... I just recoded items that are only available when there are enough players   (This iconography simply vanishes once the pop level is reached). Note that this is based on "players who have joined" (roundstart + latejoin), not "players who are online" or "players who are alive". Once an item becomes available it will never stop being available, but it only becomes available based on people who are playing and not watching. Currently the only items I applied this to (with a value of 20 players) are: - Dual esword - Sleeping Carp - Spider Extract (the spider antagonist usually requires like 27 players) - Romerol It isn't applied to anything else. ## Why It's Good For The Game Reputation isn't really a tool used to designate how dangerous an item is any more (if it ever was) and resultingly it doesn't make any sense to slow its gain based on population. Some items though we maybe still don't want to show up in a "low pop" round because they'll create an overall unsatisfying experience, so we should be able to remove those items from play. ## Changelog 🆑 balance: Traitor reputation now advances at a fixed rate, not dependent on current server population. balance: The dual esword, sleeping carp scroll, spider extract, and romerol vial cannot be purchased if fewer than 20 players have joined the game. /🆑 |
||
|
JacquerelandGitHub
|
23ac16411d |
Removes Secondary & Final Objectives from Traitors (#89466)
## About The Pull Request  Pre-discussed with @Watermelon914, this PR removes Secondary & Final Objectives from all Traitors, rather than just midround ones. It also removes all of the surrounding supporting code. Randomly assigned Primary Objectives still exist, I just used the ability to rewrite mine to take the screenshot. In terms of final objectives, the surrounding items that were available still exist but don't necessarily have sources. If anyone has good ideas for readding these in some other form it can be done in future PRs. It also allows all traitors to buy the Contractor kit, previously limited to midround traitors which lacked secondary objectives, because now all traitors lack secondary objectives. This essentially limits all traitors to a maximum of 20 TC (16 if they spawn with an uplink implant). Currently I don't foresee that they strictly need any additional way of gaining TC during a round as 20 is quite sufficient, but it may take some time to adjust and get used to it after such a long time of having access to more. If we need to adjust the starting value or add a slow drip of more points over time or something, that can be done in followup PRs. This also removes the ability to recreate your uplink added by my beautiful wife in #74315 This was part of the progression traitor design document, but ultimately probably a bad idea as it essentially made traitors impossible to properly disarm. You will once more just need to carefully protect your uplink. **This does not remove the threat/progression system**. Like midround traitors, all Reputation requirements on gear are now simple timelocks, most of which will have elapsed by the time 30 minutes have passed. **Finally** this PR also adds Romerol to the traitor uplink for 25 TC and 30 minutes of reputation, as a treat (and because I removed the final objective that previously granted it). ## Why It's Good For The Game We've tried this system for a long time (3 years last month!) and while I think it had a lot of promise, enabled some cool moments, and also solved several of the problems it set out to solve, overall I think some of the behaviours it has encouraged in players have been overall negative for the game. While the _game systems_ are fine, even quite fun and cool (especially final objectives) I am of the opinion that having them in the game creates a net negative purely in the way that they react with players' _brains_, creating incentives towards behaviour we don't actually want people to pursue. While it's hard-to-impossible to prove any of this with hard data, there has been a prevailing feeling for some time among many (though certainly not all) people that the simple fact of _having_ a constant drip-feed of objective available to players leads directly to less interesting antagonist play. While certainly nobody is _forced_ to do secondary objectives you are directly and quite strongly rewarded for doing so, doing so efficiently, and doing so in a way which makes sure that nobody (alive) sees you do it. This leads to a tendency to play defensively and try to maximise the number of tasks you can complete in one round, which also has a knock-on effect of generally minimising the number of people you attempt to interact with in a round (unless you are killing them). Even people who _intend_ on doing some more interesting gimmick can fall into this trap, as "having more tools" is always useful for anyone who is intending on any kind of plan at all, but then executing on the secondary objectives again incentivises you to lay low, not interact with anyone, be efficient, and then reduces the time you are spending doing the thing that's your actual plan for the round. Removing the ever-present temptation to fish for extra TC leaves "doing whatever your actual plan is" as the sole thing to optimise. Final Objectives too have created unfortunate psychological effects between crewsided players and other antagonists. Because of the _threat_ (no matter how remote, Final Objectives have always been tuned to be appropriately rare) that leaving any antagonist alone will cause them to snowball by acquiring more power, it starts to feel foolish to respond to any threat with less than the maximum possible level of force even if they seem relatively innocuous in the moment. This even has an effect on other non-progression antagonists, as traitors are the most common antagonist type and how people treat them is going to be their default level of reaction to most other station threats. While there has always been the promise of expanding the system with novel and exciting objectives that leverage appearing mid-round to do something unique, we've taken very little advantage of that over time. Most objectives we have added that didn't boil down to "kill someone, with a twist" have been somewhat unsuccessful, serving either as ways to get yourself arrested and killed for no reason or ways to get free telecrystals by doing something the crew don't really care about stopping you from doing. The option still exists to add more roundstart objectives to traitors, if someone suddenly has a great idea that would fit in this space. The ideal outcome of making this change is a slight relaxation of crew attitude towards feeling like their only option after catching an antagonist that isn't sandbagging is to permanently remove them from the round (although it's fine to do this still in many scenarios), and a broadening of traitorous activity which is not purely focused on collecting as many checkboxes as possible and might give people more time to roleplay with other players, not worrying that this time could have been more efficiently spent pursuing a different secondary goal. I don't anticipate or desire that this will prevent traitors from killing anyone (or even stop them from killing people they don't have a specific objective to kill), I just want to remove the FOMO from people's minds. Also this gives us something to talk about at the coder townhall meeting on the 22nd. ## Changelog 🆑 del: Misplaced or stolen traitor uplinks can no longer be recreated using a radio code and special device, guard yours carefully or buy a backup implant. del: Roundstart traitors can no longer take on additional objectives in order to earn additional Telecrystals and fast-forward any unlock timers on items. They also cannot earn the ability to complete a Final Objective. balance: Roundstart traitors can now buy the Contractor Kit from their traitor uplink, rather than only midround traitors. add: Traitors can buy Romerol for 25 TC, after 30 minutes of time has passed in a round. /🆑 |
||
|
IamgoofballandGitHub
|
e1208872be |
Adds an off-by-default config option to optionally disable TTS audio on whispered speech. (#88826)
## About The Pull Request Adds an off-by-default config option to optionally disable TTS audio on whispered speech. ### Ignore the Wallening. It's an old branch and I like to be nostalgic of what could've been. https://github.com/user-attachments/assets/f97aad31-9a83-421f-a3f0-0c0e54256664 ## Why It's Good For The Game We're trying to claw back as much performance as possible from our TTS engine and there's literally no reason to play TTS audio if nobody but the person speaking into the radio is going to hear it. Requested by the host. Config is off by default. ## Changelog 🆑 sound: Adds an off-by-default config option to optionally disable TTS audio on whispered speech. /🆑 |
||
|
grungussussandGitHub
|
bd0c33b9bd |
unhandicaps station drones (#87983)
## About The Pull Request - makes area-based shy-ness for drones config - reduces the cooldown on touching machines as a shy drone from 1 minute to 20 seconds ## Why It's Good For The Game This was admin issues solved by codebase, no one plays drones anymore and those who do - complain that they're not fun because of the heavy restrictions imposed upon them. If I remember correctly - the playtime restriction on our servers is 20 silicon hours? or 10 silicon hours? It's a config thing I can't check. This means it shouldn't be a problem with ban evaders and such. Area restrictions are odd because drones can't get more air from atmos and they can't make power from SM, which is in their laws. If a drone is messing with your SM then kill it, or ahelp if it keeps coming back? For context: ``` "1. You may not involve yourself in the matters of another being, even if such matters conflict with Law Two or Law Three, unless the other being is another Drone.\n"+\ "2. You may not harm any being, regardless of intent or circumstance.\n"+\ "3. Your goals are to actively build, maintain, repair, improve, and provide power to the best of your abilities within the facility that housed your activation." ``` ## Changelog 🆑 grungussuss server: drone area restrictions are now config balance: drones now take less time to become "un-shy" of something after it's been touched. /🆑 |
||
|
CliffracerXandGitHub
|
b9f171109e |
Human authority defaults edit (#87380)
## About The Pull Request Extremely simple PR that edits the defaults for the new config options added in #86886 - this restores the default behaviour that was in place before #86886; human authority is disabled but easily restored to TG norms by uncommenting the associated line in the config. This doesn't impact any of the TG servers directly since they're all on TGS and have static config files, but this does avoid downstreams being blindsided by their configs mysteriously breaking and test instances having behaviour change. I spent an embarrassing amount of time trying to figure out what *I* broke the past day, only to realize it was an upstream issue breaking configs all along, and I strongly suspect I won't be the only one. ## Why It's Good For The Game No impact on the TG playerbase directly, this is just for the sanity of developers and downstreams that use static configs. More time spent being productive, less time spent wondering if your PR buggered up spawnin and humanized everyone. ## Changelog 🆑 config: altered coded defaults for human authority, no impact on TG /🆑 |
||
|
|
2f4db9bb65 |
Adds more extensive config settings for human authority (#86886)
## About The Pull Request Before there were two settings for human authority: `ENFORCE_HUMAN_AUTHORITY` and `ENFORCE_HUMAN_AUTHORITY_ON_EVERYONE` The first, if enabled, would not let non-humans be heads of staff unless they had a specific var on their job set to TRUE. The second, if enabled, would simply ignore that var and reject the non-human anyways. This PR replaces both of those settings with a single one, `HUMAN_AUTHORITY`. You can set it to one of four settings: * "OFF": human authority will be turned OFF. Non-Humans will be able to be heads of staff. * "HUMAN WHITELIST": human authority will be turned OFF, HOWEVER; if a job has its new `human_authority` variable set to `JOB_AUTHORITY_HUMANS_ONLY`, then whoever picks that job will be forced to be human. * "NON-HUMAN WHITELIST": human authority will be turned ON. However, if a job has its `human_authority` variable set to `JOB_AUTHORITY_NON_HUMANS_ALLOWED`, a non-human can become that job. This is what we have now, it works the same as if `ENFORCE_HUMAN_AUTHORITY` were turned on. This is also what I've set as the default value. * "ENFORCED" human authority will be turned ON. Non-Humans will never be able to be heads of staff. This is what `ENFORCE_HUMAN_AUTHORITY_ON_EVERYONE` used to do. You can also now set the `human_authority` variable through `jobconfig.toml`! ## Why It's Good For The Game Allows more configuration options for downstreams, and lets keyholders and headmins have more options over how to set up human authority. ## Changelog 🆑 config: Both human authority settings were combined into a singular one, allowing for more flexibility /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
GhomandGitHub
|
e00eb5ec6a |
Added a config to override the def gateway delay for specific start points. (#85341)
## About The Pull Request I've a few gripes with start points and the gateway delay. First of all, there's no way to discriminate peaceful away locations that do not need a with a 30 minutes timegate from the rest. Places like the beach and the museum hardly have anything OP that could tip the scales. Second, none of the awaystart landmarks have identifiers of their own, which means all awaystart landmarks from all away missions are linked under the same destination point datum. This is hardly an issue in the current state where only one map is ever loaded and all maps have only one way in that directs you to one of several locations at least until the gateways are linked, but it's nevertheless something that I have to take care of, since the config requires it. ## Why It's Good For The Game See above. ## Changelog 🆑 config: Added a config for specific gateway delays so locations like the beach and the museum don't have to take 30 minutes to become available like the rest. /🆑 |
||
|
larentounandGitHub
|
5407a96a98 |
Adds TRAITOR_SCALING_MULTIPLIER to config and makes it a float value (#85162)
## About The Pull Request Added a missing entry to game_config.txt Fixed this entry being an integer, not a float ## Why It's Good For The Game Config can be used to modify the speed at which the traitors progress. It was missing from the example config. ## Changelog 🆑 config: Added an entry for TRAITOR_SCALING_MULTIPLIER, disabled by default /🆑 |
||
|
GhomandGitHub
|
9032f8ccff |
[NO GBP] the random spawner loot weight config is not an integer (#84814)
## About The Pull Request Sets `integer` to false. Also a tidbit about the `skew_loot_weight` proc, though loot lists with uneven weights all tend to add a value to all entries so it isn't an issue. ## Why It's Good For The Game The config isn't an integer. ## Changelog N/A |
||
|
GhomandGitHub
|
7be649a7f6 |
Adds a config that skews random spawners weights. (#84616)
## About The Pull Request Title. It's an exponent that multiplies weights of random spawners. For example, if the exponent were 0.8, and the spawner has a natural 99.9% chance to spawn a donk-pocket and a 0.01% of a vial of adminodrazine, after calculations it'd be roughly 99.6% vs 0.4%. ## Why It's Good For The Game This can give admins/keyholders more control over random spawners. ~~However, most of the random spawners are maploaded things so an admin would've to get to edit the config quite fast before SSatoms initializes to witness the most out of it, but I'm just ranting.~~ ## Changelog 🆑 admin: Added a config that regulares random spawners weights. /🆑 |
||
|
|
9d2c02e691 |
make SSevents frequeny_lower and frequency_upper configurable, fix runtimes when no events were drafted to trigger (#82978)
## About The Pull Request Make events frequency configurable. Fix runtime when no events were drafted to be picked from. ## Why It's Good For The Game No runtimes good. No need to change frequency in code. 🆑 fix: fix runtime when no events were drafted to be picked from config: make events frequency configurable /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
ProfakosandGitHub
|
b20c982404 |
Converts slimes to basic mobs (#82176)
## About The Pull Request After months of preparation, and further months of work, I am finally done. Please bear with me, as this is a massive refactor, but I have already atomized everything I could. This is now ready for review. General - The hilbert hotel slimes are now a subtype instead of a varedit. - The `use_mob_ability` subtree now also accepts non cooldown abilities. If set_behaviours is set up properly, mobs won't keep continously triggering it as if it were a 0 second cooldown action. The alternative would have been turning the slime abilities into cooldown abilities. - Wrestling off a slime now signs up to the `COMSIG_ATOM_ATTACK_HAND` signal, instead of being part of attack_hand. - Adds datum/ai_controller/controller as a fourth, optional argument to `/datum/ai_behavior/find_hunt_target/valid_dinner()` to make it possible to access blackboard keys. - Slimes no longer attack windows if they would accidentally move into them (when the conditions are met), since random walk behaviour ignores tiles they can't go in. It was also not worth to keep. Did you know this was the sole override of `ObjBump()`? - Examine was made less snowflaky/bespoke. Also added a new element: `/datum/element/basic_health_examine`, which is a simple bespoke element that prints out a custom message based on how damaged the basic mob it is attached to is. - Slimes only perform knockdown instead of paralysis, as they can attack more often now, and paralysis is not that fun. - LAssailant has been removed due being archaic code. To befriend a slime, you have to spawn a monkey with the slime console, or feed them a sheet of plasma. Simple grabbing the monkey or stuffing them in disposals do not work anymore. Slime console spawned monkeys will have a visible status effect, with pheromones coming off them to make this clearer. Actions - Feeding, reproduction and evolution is no longer a verb. - Slime feeding is no longer an action button. You have to use right click, or as previously, mousedrop. Slimes can always unbuckle from mobs they are attached to. Hunger - Instead randomly changing the starvation and max nutrition values while growing up, evolution costs 200 nutrion. This makes the code more readable, and behaviour more predictable, while still giving the intended time between evolving and splitting. As a result, I could also turn these into defines. - Added a component that handles doing an effect over time while buckled to a mob, until the mob dies or you get unbuckled. - Slimes gained nutrition is no longer randomly multiplied by the damage config value, but rather gain nutrition equal to twice the damage dealt. You'll have to eat one monkey to evolve, just as before. - Slimes do not heal passively. They only heal from eating. It was a rather miniscule value that did not have much effect. - Slimes generate electricity from hunger threshold, instead of the random amount of hunger threshold + 100. Environment - Slimes take 15 damage from cold every second, instead of using a complex formula (that also decreased the damage up to a point?). - Slimes still heal from burn damage, but this is now set on the damage coefficient list. - Slimes instead of getting stunned by the cold, freeze in an ice cube. BZ instead of setting them unconscious, calls the stasis status effect, allowing you to safely stash your hungry slimes for later. They also no longer slow down from the cold, as they are already slowed down by the damage they get. Conversely they no longer get a speed up from a random amount of temperature. I could be convinced to readd this either as part of the basic sensitive component, or a similar one. AI - Removed the attacked_stacks system. Slimes will just perform regular retaliation if you hit them in a harmful manner. - Slimes now use the pet orders component. They will interrupt their feeding when given a command by their master. - Slimes have their own subtrees. I tried to replicate as much as I could from the old code, dividing ancient code artifacts and intentional stuff, so there might be some weirdness. - Slime speech has been almost fully reduced to basic blorbing, as you can not even understand them anymore, and most of them require the slime to loop through all of their surroundings. - Discipline does not have stacks either. Disciplined baby slimes have a chance to clear their attack and hunt blackboard keys. All slimes will stop feeding on the target otherwise. - Since discipline is not a stack, rabidity instead gets removed at a 10% chance per disciplining. - Slimes faces are a bit more randomly picked now. ## Why It's Good For The Game - We want to convert all simple animals to basic mobs. Old slime code was also very strange, and had some systems that have been replicated by components. - Slimes fully paralyzing you is not fun at all. Knockdown should give you a fighting chance when a slime would like to eat you. - Slimes slow down from the heavy damage they get from the cold, so I don't think they need extra slowdown, nor do they need to speed up from warmth, as they are already fast. - Slimes turning into an icecube instead of becoming paralyzed from the cold is more fun for the slimes, as they can break out for a few moments. It is also funny. - Slimes entering proper stasis from BZ is not just a visual indicator of a slime that is safe to approach, but also keeps the slimes's hunger value in check, allowing it to not starve while stopped. They can also look around and blorble, instead of staring at a black screen, if player controlled. - The attack_stack and discipline_stack behaviours were rather overcomplicated, and the xenobio mains I talked with didn't even know it was a thing, so I argue it needed simplification. - The bespoke friendship system of slimes was also too complicated. Slimes slowly gained levels of trust, and at certain levels commands costed friendship, and other levels, they did not. The binary friend/not friend system that everything else in the game uses is much more sensible. - Using right click for feeding is much more sensible than using an action, and then picking someone from a dropdown. - Slime speech was very soulful but not only did it loop through everything in sight, you couldn't even understand it unless you spoke slime. Maybe it can be readded later in a different form. - Slime's passive healing was miniscule, and having them rely on feeding is more interesting. also fixes #81463 ## Changelog 🆑 refactor: Slimes are now basic mobs. Please report any strange behaviours! balance: Slimes only stun you for two seconds when they shock you, the rest of the duration is a knockdown. balance: Slimes are not stunned from the cold, but rather, get frozen in a freon icecube. BZ also puts them in complete stasis, instead of making them unconscious. Their speed is likewise unchanged by temperatures. balance: Slimes do not passively heal, they instead rely on feeding. fix: Slimes can use the buckling screen alert to unbuckle and stop feeding, along with clicking on the mob they are riding /🆑 |
||
|
Dani GloreandGitHub
|
495fde6a2c |
Add: 2 Quirks Configs (#81033)
## About The Pull Request This PR adds two new config options for quirks: - *Flag* `DISABLE_QUIRK_POINTS` - When enabled, disables quirk points balancing. - When enabled, players can select positive quirks without first selecting negative ones. - When enabled, the quirk points balance visually hides itself on the Quirks page. - *Number* `MAX_POSITIVE_QUIRKS` - Limits the maximum quantity of positive quirks which players can select using the Character Preferences page. - I ported this from the old `MAX_QUIRKS` define. - When set to `0`, players won't be able to select any positive quirks, and they won't appear on the Quirks page. - When set to `-1`, players will be able to select any quantity of positive quirks. - When commented-out or undefined, the default is `6`. - When set to `0` or `-1`, the positive quirk balance visually hides itself on the Quirks page. ## Why It's Good For The Game There is some downstream repositories asking for the quirks system to be configurable. Additionally, I always find myself tweaking these values on my own private servers and I thought it would be nice to share my edits. Usually I was simply commenting-out sections of this code in order to get the same result, so it helps to have an official way to disable quirk points. ## Changelog 🆑 A.C.M.O. config: Added two new config flags for quirks, DISABLE_QUIRK_POINTS and MAX_POSITIVE_QUIRKS. /🆑 |
||
|
GhomandGitHub
|
a59cebea56 |
Increased odds of station traits a little. Introduced a "budget", so smaller traits only take half as much space. (#80211)
## About The Pull Request Recently, I chatted with others about how few station traits are rolled on a round by round basis - about 59% of the shifts go without either positive or negative traits for example - and how the mild most of these traits are (not a bad thing per se), which results in an underwhelming feature, despite the more interesting bits of it. So, after sharing opinions, I've decided to make this PR to increase the rolls and odds a bit. EDIT: After reading comments and taking some time to think this thoroughfully, I've decided to push the probabilities back a little in favor of a simple budget system for station traits, to allow for smaller things to only count as half a station trait. This mean smaller traits won't necessarily stop "better" ones from rolling, or at least allow for plentier permutations of traits that do not affect the round TOO much. I've also reduced the weight of the glitched pda beeps trait from 15 to 10, the same of scarves, wallets and colored assistant jumpsuits. ## Why It's Good For The Game I believe the current odds of station traits to be a smidge low, and that the lack of any sort of cost-budget for station traits to hurt the rarer, more interesting traits (and the feature in general) if the more common, milder ones take just as much space. It's totally within the spirit of the feature to have small, niche traits, though they can get quite boring pretty fast on their own, so what I'm saying is that their cost should stay low so that other traits can roll. ## Changelog 🆑 refactor: Introduced a simple budget system to station traits, so that smaller things only count as half a trait, for example. balance: Increased the odds and maximum number of station traits that can be rolled each shift. /🆑 |
||
|
|
63c7e88156 |
Alert a Discord role when a new player joins (#77432)
## About Why It's Good For The Game The Pull Request What it says on the tin. A requested feature for people who like to keep an eye on swaths of new players. A config that is off by default, but a Discord role ID can be added to have TGS ping that role. Also sends alerts to Discord if a player with sketchy telemetry joins. ## Changelog 🆑 Tattle admin: Pings an admin role on discord when a new player joins (when enabled by config) /🆑 --------- Co-authored-by: tattle <article.disaster@gmail.com> |
||
|
|
fc854e7076 |
Removes TTS voice disable option (#76530)
## About The Pull Request Removes the TTS voice disable option, which was already unavailable on TG as it was set to off by default. The reason this was added was so that downstreams could toggle the config on or off. ## Why It's Good For The Game I think this option fundamentally undermines the TTS system because it allows individual players to disable their voice globally, meaning that players who have TTS enabled will not be able to hear them. This worsens the experience for players who have TTS enabled and it's not something I want to include as an option. If players don't like their voice, they can turn TTS off for themselves so that they don't hear the voices. If players don't want to customize their voice, they can quickly choose a random voice, and we can take directions in the future to make voice randomization consistent with gender so that a male does not get randomly assigned a female voice and vice versa. This option is already unavailable on TG servers because it was primarily added for downstreams, but I don't think giving downstreams the option to undermine the TTS system is the right direction to take. Downstreams are still completely free to code this option on their own codebase. --------- Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com> |
||
|
|
a159b52e85 |
TTS Improvements: Improved Audio Quality, Pitch Adjustment, Preference Silicon Voices, Per-Character Voice Disable Toggle, Tongue Voice Filters, Reworked Silicon and Vending Machine Filters (#76129)
## About The Pull Request https://github.com/tgstation/tgstation/assets/4081722/5ca8e015-21f9-4159-9953-bc370152d01f Improves the audio quality and speaker fidelity by implementing Retrieval Voice Conversion as an intermediary layer, utilizing the repository at https://github.com/ddPn08/rvc-webui. Leverages RVC to allow players to set a pitch for their voice. https://github.com/tgstation/tgstation/assets/4081722/0eb76ed7-ad67-4da2-9ceb-02605eea2c83 Makes silicons utilize a player's chosen voice preference on their character slot, and adds a preview button to hear the voice as a silicon on character creation. Adds a toggle on character creation to disable having a voice on a specific character slot. Adds support for per-tongue voice filters. Reworks the silicon voice effect to be a special effect done on the TTS server level instead of via normal filters. Reworks the vending machine effect to use the new robotic voicebox effect. ## Why It's Good For The Game Vastly improves the audio quality and speaker fidelity of our TTS system. Allows players to further customize their voice per character, naturally pitching the voice up or down with cutting edge machine learning based pitch adjustment. Allows silicon players to have a consistent voice that's also audible and understandable regardless of the voice or pitch of the speaker. Improves vending machine audio quality. Enhances the immersion of snail tongues and robotic voiceboxes. Adjusts how Poly's pitch adjustment works based on if RVC is available or not. Allows players who feel that a voice doesn't fit their character to disable having TTS on their specific character. Provides server operators a way to disable specific voices in situations with a shared voice server. ## Changelog 🆑 Iamgoofball, Nadare, ddPn08, Mangio621, the rest of the RVC dev team add: Improves the audio quality and speaker fidelity by implementing Retrieval Voice Conversion as an intermediary layer, utilizing the repository at https://github.com/ddPn08/rvc-webui. add: Leverages RVC to allow players to set a pitch for their voice. add: Makes silicons utilize a player's chosen voice preference on their character slot, and adds a preview button to hear the voice as a silicon on character creation. add: Adds a toggle on character creation to disable having a voice on a specific character slot. add: Adds support for per-tongue voice filters. add: Reworks the silicon voice effect to be a special effect done on the TTS server level instead of via normal filters. add: Reworks the vending machine effect to use the new robotic voicebox effect. /🆑 --------- Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com> |
||
|
IndieanaJonesandGitHub
|
daa33d89fe |
Xenomorph/Alien Rework 2023: Part 1 (#75286)
## About The Pull Request Alternative to #75277 Kept you waiting, huh? This PR is the first part of a Xenomorph rework which seeks to make the big lugs more balanced and up to date with /tg/'s current design. This mainly involves curtailing xenomorph's infamous hardstuns into more interactive forms of combat, while also giving some buffs to the xenomorph's more unique abilities in order to keep them threatening. Part 1 will focus on simple number changes and some simple mechanic changes. In the future, changes will be made to endgame involving xenomorphs, along with changes to other facets of Xenomorphs. Highly based off of #55937. Changes: - Xenomorph disarm has been completely reworked. While a disarm will attempt to, well, disarm, a human opponent should they be holding something, it will no longer immediately hardstun targets when they aren't. Instead, the xenomorph will shove the target several tiles back and inflict 35 stamina damage. If the target slams into a wall, this will also come with the added effect of knocking them down. If a human is incapacitated, however, right click will slam them into the ground, which paralyzes them for a lengthy 5 seconds (which is ultimately half the time xenos could stun you for before), allowing for safe transport back to the nest as long as you keep them close. - Humans can now shove xenomorphs. Due to being the superior predator, however, you can't knock down xenomorphs from shoving. You can slow them for a little bit akin to humans though. - Neurotoxin no longer is a hardstun. Instead, it deals 50 stamina damage on contact. It is still resisted by BIO armor. **HUNTER:** - Speed reduced from -1 to -0.3. - Pounce speed is twice as fast as before (1 to 2) - Hardstun time on pounce reduced from 10 seconds to 5 seconds. Hunters being insanely fast has been a major balance-ruining factor of xenomorphs for many years now. These buggers could practically ambush anyone, hardstun them immediately, and then leave before anyone could do anything. Now, with their speed nerfed and in combination with the xeno shove changes, hunters will need to spend more time to down a target. Their pounce was practically useless, so its been sped up in order to make it more practical to use. **SENTINEL** - Speed reduced from 0 to 0.2 - Cloak alpha reduced from 0.75 to 0.25 (you're more hidden now) Sentinels receive a large nerf in regards to their spit, but their before useless cloaking ability has been greatly improved upon as compensation. They now serve better as defenders and ranged ambushers. **XENOMORPH DRONE** - No changes As in the original PR, drones are perfeclty balanced in my eyes, so no changes were required. **XENOMORPH PRAETORIAN** - Speed increased from 1 to 0.5 - No changes Praetorians get affected by the nerfs of the other xeno abilities, but now they're a bit faster in order to close the gap to use their abilities. **XENOMORPH QUEEN** - Speed increased from 3 to 2 - Health increased from 400 to 500 - Damage increased from 20 to 50 Xenomorph queens have been sped up and made more tanky and lethal in close-range combat. Fighting this beast up-close should be a death sentence to almost anything else in the game. Speed increases will help her re-position and close the gap on potential prey. **OTHER CHANGES** - Fixed a bug where simplemobs didn't actually use xenomorph's damage values when they were attacked by them. ## Why It's Good For The Game Xenomorphs are old, and haven't been updated for quite a long time. This has left them as sources of a bunch of hardstuns which made counterplay from a modern spaceman extremely difficult. With these changes, fighting xenomorphs is more interactive and should end up being more enjoyable for both crew and xenos. Buffs were also given out to incentivize usage of xenomorph's unique abilities as opposed to the standard disarm spam which was most effective for them until now. ## Changelog 🆑 balance: Xenos have been rebalanced, removing their hardstuns on their disarm and neurotoxin, along with a slew of other changes. Xenos have received buffs to their more unique abilities in return. fix: Fixed simplemobs ignoring xenomorph's melee damage values when being attacked by them. /🆑 |
||
|
|
a98706ff8b |
Adds TTS to the game. Players can select their own voices in preferences. (#74775)
Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com> Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com> Co-authored-by: Iamgoofball <iamgoofball@gmail.com> Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com> Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
ComxyandGitHub
|
30a425d99f |
Fix Basic Mob Speed (#75306)
## About The Pull Request All basic mobs became slower because of #75186. This fixes that. ## Why It's Good For The Game Intended speed. ## Changelog 🆑 fix: Fixes the speed of all basic mobs. /🆑 |
||
|
larentounandGitHub
|
4dfebd58e9 |
fix: Basic mobs' multiplicative movespeed (#75186)
## About The Pull Request Adds default multiplicative movespeed for basic mobs, so their speed is configurable via config. ## Why It's Good For The Game Closing things which were probably missed in the development of basic mobs ## Changelog 🆑 code: Adds default multiplicative movespeed for basic mobs, to make them editable in config config: Default multiplicative movespeed for basic mobs in example config /🆑 |
||
|
|
8c056a46d4 |
Station shift start time config (#74711)
## About The Pull Request We have a config flag to set random shift start times or server sync'd start times, but not one to simply set the shift start time. ## Why It's Good For The Game Control over the shift start time. This way events such as breakfast can occur during actual breakfast hours. ## Changelog 🆑 LT3 config: Station shift start time can now be set in the server config /🆑 --------- Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com> |
||
|
LemonInTheDarkandGitHub
|
8982828d05 |
Removes Starlight Config (#74289)
## About The Pull Request It was config'd off to save init time, but having it function in testing and mapping is more valuble then the time spend on it. On that topic, we spend roughly 1.7 seconds of init on this. ~1.3 is spent handling the light sources and their light object modifications (this is potentailly inflated since other sources could cause the same objects to need updates) ~0.3 is spent searching for space turfs around lighting_objects during init. This will impact change_turf slightly too, costing about ~0.07 in local testing. It does save time for live however, since we avoid these config checks. ## Why It's Good For The Game I believe this time is worth spending. I've had people try to "fix" artifacts of starlight not being enabled, things that aren't bugs. The test environment should as much as we can make it reflect the visual reality of the game. This helps ensure that ## Changelog 🆑 server: The starlight config has been removed, as it is enabled by default /🆑 |
||
|
|
9740f104d0 |
Contextual tutorials for swapping hands and dropping items (#72292)
# Requires https://github.com/tgstation/tgstation/pull/72320 ## About The Pull Request https://user-images.githubusercontent.com/35135081/209700892-e54be6cf-d18c-4d12-acd1-e5eb46e9d82d.mp4 https://user-images.githubusercontent.com/35135081/209700911-751b8a0e-d770-49fa-a6eb-ce50aa0fa670.mp4 --- Adds a system for tutorials that: - Are contextually given - Are not given again after completion - Can optionally not trigger for anyone who first played before a certain date Uses this system for a tutorial for switching hands/dropping items. This tutorial is triggered when you try to click on an item with another item, and `afterattack` return FALSE. In order for this to work as smoothly as possible, I'm going to open a separate PR that cleans up the `afterattack` on everything to either return TRUE/FALSE. ## Why It's Good For The Game SS13 is an extremely confusing game, being able to do tutorials in a non-intrusive way (like a separate tutorial mode) is nice. The system in place is going to be perfectly usable for introducing mechanics to both fresh players and experienced players alike (such as for future content). ## Changelog 🆑 qol: New players will now get a contextual tutorial for how to switch hands and drop items. /🆑 Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com> |
||
|
MothblocksandGitHub
|
c2a3ba8b75 |
Add config for station traits (#72408)
Adds a config for station traits. Extremely annoyed of testing locally and having all the lights break or spawning in the shuttle puking or whatever. |
||
|
TimandGitHub
|
6d12dc69ef |
Refactor /mob/living/carbon/alien/humanoid to be /mob/living/carbon/alien/adult (#70481)
|
||
|
|
c7e03e4048 |
Add silicon human spremacy override config, fixes #68957 (#69293)
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
san7890andGitHub
|
5dc17bd865 |
Security's Scaling Departmental Accesses - More Pop, More Problems (#68534)
lternative to #68527 About The Pull Request Hey there, This is an alternative PR that I concocted based on talking with Goof on that PR. Basically, we already have a nicely complicated system to track and balance the number of security officers we have in a shift based on some config coefficient setting, by which we can set the amount of lockers that spawn in on the start of a round, as well as determine truly how many security officers we have. image So, I've decided to leverage this in another way. Basically, based on the number of security officers in a shift, their specific departmental officers will also get more (elevated) accesses. They already start with a certain amount of access, but they can get more if it is a low-pop shift with the mechanic introduced in this PR. For example, an Engineering Security Officer can access Atmospherics and Engineering departments by default, but they can't access Telecommunications unless there is a lower population of players AT SHIFT START. Same for a Medical Security Officer accessing Medbay, but not Plumbing. Update: I have made it such that there are three system that server operators can set: They can use the Scaling System that operates in the same method outlined in the rest of the PR. They can disable giving departmental security officers "elevated access" (such as access beyond the "front doors") to these officers. Finally, they can also just always ensure that departmental security officers get the maximal accesses possible. The default setting is the "Scaling System" outlined in this PR, which is already dependent on the general Security Officer Scaling Co-Efficient. Why It's Good For The Game I think it's better to involve some more nuanced config scaling that we already have present in the game. The major theme that we want to avoid is that departmental security officers having maximal accesses when there is an already large number of persons on the security force will result in "miserable" shifts for the common person working within a department (security metaprotections). However, some server operators (as well as server cultures) tend to have very wide ranges in how many security officers they have on a shift-by-shift basis. One day, you could have 0-2 security officers, the next, you could have 4-6. It's all variable on who's playing (as always). There is also a significant variation between server to server in regards to how many security officer slots you tend to have on spawn, but this is already manageable by the security officer co-efficient in config. I believe this PR is an acceptable proposal within the bounds of #68527 (comment) , although it may bend certain aspects of it, I definitely do see where some people may be coming from. I believe I've adjusted the accesses to a "sane"/justifiable amount, but I'll come back to think on everything. "Red-tiding" may or may not be a problem, but there's always just going to be something inherently silly with a security officer being able to walk into plumbing to start plumbing. I hoped that this would be seen as a positive as opposed to a negative, but I can see how it could negatively impact player experience. HOWEVER, interplayer experience should not be handled by the codebase in all aspects, which is why I've also passed in the associated config variables, so that server operators (who should handle the interplayer experience with their level of discretion and nuance) can. What accesses are where? The general philosophy as I thought through designing this would be that the security officer should at the very least have general "front-door" access into a department, and maybe something benign. If we had even more per-door accesses, this could definitely be a bit more granular (one example I can think of would only atmospherics technicians having access to the "Pump Room", while Security Officers would not. However, this is for a later date). So, you have the "default" access you always get, and a potential to get "elevated" access as a Departmental Security Officer. The balances are as such: The Cargo Security Officer will have access to the Cargo Bay, Mining Section, and the Shipping Room. The first two are rather general areas, with the Shipping Room being a rather good help for rescuing (or "rescuing") flushed crewmembers when the cargo techies can't get to it/no AI. The Auxiliary Base is not essential to the security officer's functions, and the mining station helps restrict access further on stations like IceBox. This would also grant them extra access to the Lavaland base, so let's snip that out. The Engineering Security Officer should have access to only general Engineering and Atmospherics. Construction pertains to certain rooms in maintenance I believe, and Engine-Equipment should be the one that grants access to APCs (lol). I don't think a security officer should have the latter one to be honest, but I think we'll be stretching the scope of this PR. Telecommunications is a bit weird, it's a critical station function, but I think you also shouldn't be able to nick one goon's ID and have access, so let's give it to them only when it's "needed". The Medical Security Officer should have access to only the general Medbay Area and the Morgue, in case someone starts trotting on the doctor's turf, or if there's someone doing unsavory things to the bodies while the doctors are away. They will not have access to the specialized (dangerous) areas unless the ratio of secoffs to the population is low enough should it necessitate it (Plumbing Room, Pharmacy, Virology). I also added Surgery to the scaling access, but I'm iffy on that one. I don't particularly see why they should have it as a base access, but I also do see there being some need in dire straits (in relation to helping people, not tiding). The Science Security Officer definitely got a huge cut. They now only have general access to R&D and normal scientist areas like the lathe room, circuits lab (presumably)since these are generally trafficked areas, but I definitely clamped down on additional access they might get in a "normally balanced" situation (no ordnance+storage, no xenobio, no genetics, no to robotics, etc.) They don't have a particular use in these areas and can even be a bit obstructive to flow in normal circumstances, but if abnormal circumstances arise and there's not a lot of security hands-on-deck, then their access is expanded. Honestly, balancing this both makes sense and is conversely rather odd. I'm just running off what we already hold to be true and expected (or at least as of the last two months), and we can go from there. Changelog cl balance: Nanotrasen realized that the more access they had on their cards was costing them a pretty penny, so they trimmed back the number of accesses a certain departmental Security Guard might have. However, any given guard will get back a greater amount of accesses depending on how many security guards there are in relation to the population. config: Hey server operators, listen! We've changed up how Departmental Security Officers get their accesses, so be sure to review the DEPSEC_ACCESS_LEVEL config number to see what you want to work best for your server. /cl Also, every single line of code found in 4533f07 that is now presently in this PR is deliberate |
||
|
CharlotteandGitHub
|
2a2845e252 | AI Lawset can now be specified instead of 'custom' (#68587) | ||
|
|
4e6e1f090e |
[Ready for Review] Admin lua scripting (#65635)
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
MrMelbertandGitHub
|
f8f3dbed98 |
Completely removes proc_holders from existence. Refactors all wizard, xeno, spider, and genetics powers to be actions. Also refactors and sorts ton of accompanying code. (#67083)
* destroy proc holder pt1 - change proc_holder/spell to action/cooldown/spell - docs all the spell vars, renames some of them - removes some useless vars - start with pointed spells, as they're easy * kill proc_holder pt2 - kill a buncha vars and replace it with flags - convert a ton over - general code improvements * kill proc_holders pt3 - convert a good few more spells - rename some signals - handle statpanel - better docs * kiill proc_holder pt4: - restructure the file system of action.dm, separating a good amount of item actions and miscellaneous garbage into files where they belong slightly better. Also splits off item actions, cooldown actions, innate actions, etc. into their own files, overlal making it much better to work with - converts touch attacks to actions - converts blood crawl, jaunt subtype * kills proc_holder pt5 - clears up some icon issues so all the currently converted pages don't have errors - shapeshift - some more action cleanup * kills proc_holder pt5.5: - some documentation - reworks feedback to prevent oversight with teleports and stuff * kills proc_holder pt6: - converted cult spells - converted magic missile - converted mime spells - chipped away at the errors - removed some vars which were too general, replaced them with more locally applicable vars. for example "range" which could mean "projectile range" or "aoe radius" or whatever - instead of having a broad net which everyone applies to in a confusing matter, instead lets each spell delegate on their own. - merged magic/spell and magic/aoe, as the comment intended - more unified behavior for spell levelling * kill proc_holders pt 6.5: - replacing a buncha old proc_holders that have been updated to reduce some errors. sub 900 baby * kills proc_holder pt 6.75: - minor fixes * kills proc_holder pt7: - cuts down on some errors - refactors some wiz events * kills proc_holder pt 7.5: - malf ranged modules - some minor errors * kills proc_holder pt 7.75: - mor eminor error handling, cleaning up changes * kill proc_holder pt8: - refactors spell book - refactors spell implant - some more minor error fixing * kill proc_holder pt 8.5: - scan ability * Adds some robust documentation * kill proc_holder pt9: - converts some / most mutations over * kill proc_holder pt10: - sort out all the granters - refactor them slightly - fix some compile errors * Some set-unset sanity - going to need to test removing Share() * Removes transfer actions. It doesn't seem to do anything. - Transfer_actions was called when current = new_character so locially speaking the early return in Grant() should cause it to NOOP. Test this in the future though * Removes sharing from actions, docs actions better * Some better documentation for spell and spell components * Kills proc_holder pt11: - Finally finishes ALL THE SPELLS IN THE SPELL FOLDER - Fixes some more errors * kills proc_holder pt11.5: - minor error fixing and sanity * Method of sharing actions. Can be improved in the future, needs testing * Implements a way to update the stat panel entry for a spell. Also gets rid of VV stuff, as you can update the bigflags directly in VV now. * Curse of madness bug I put in. * kills proc_holder pt12: - sub 500 errors! - converts cytology mobs - converts and refactors spiders slightly - some minor fixing around the place as usual * kill proc_holder pt13 - Finishes heretic spells - Sub 300 errors! - some touch refactoring to account for mansus grasp * kills proc_holder pt14: - revenant - minor bugfixing for heretic stuff * kills proc_holder pt14.5: - some missed stuff for revenant + heretic * kills proc_holder pt15: - alien abilities - more minor fixing - sub 100 errors. The end is nigh * kill proc_holder pt16? 17: - Finishes cult spells - sub 50 errors! - refactors the way charge works - renames / moves some signals * kills proc_holder pt final: - sdql spells - no more errors! * Bugfixes round 1 * Various bugfixing - documentation done - give spell works - can cast spell gives feedback conditionally - is available takes into account casting ability * Some accidental reversions + fixes * Unit tests * Completely refactors jaunting - All bloodcrawling is now handled on the action itself instead of across various living procs - slaughter demons have their own blood crawls - jaunting dummies don't have side effects on destroy() anymore * Wizard spell logging and even more refactoring |
||
|
|
273eac1096 |
Added further limitations on the sound emitter circuit component (#67540)
Added limitations on the sound emitter component Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com> |
||
|
|
c16443c8c6 |
Makes Playing Lobby Music A Config (#67455)
* Makes Playing Lobby Music A Config Hey there, Apparently some people don't like listening to the soulful lobby music we have to offer. How unfortunate. This adds a config flag to disable said title screen music. I've heard people who like debugging a lot don't want to get their ears-bleeding via flipflap, but I find it hard to agree. * ALLOW to DISALLOW whoops * FUCK * MSO's suggestions I also added a small portion in regards to player preferences in case people weren't aware of that. * lol physics burned my brain out on parentheses Co-authored-by: Kylerace <kylerlumpkin1@gmail.com> Co-authored-by: Kylerace <kylerlumpkin1@gmail.com> |
||
|
IamgoofballandGitHub
|
aebd156a43 |
CARGONIA THE FREE: The Quartermaster is now a head of staff. (#67518)
* The Quartermaster is officially a head of staff, with new accesses, a silver ID, ect ect. * The HoP lost their cargo-related equipment and access, including the Vault monitor, and frequency. |
||
|
san7890andGitHub
|
33c56a9cac |
Purges Mentions/Related Code of Virtual Reality From Config and Mapping (#67031)
Purges Virtual Reality From Config and Mapping This shit has been gone from the game since 2019, it's time to bid adieu to bloat. |
||
|
MrMelbertandGitHub
|
b9ba2d2dae |
Removes (now unused) sandbox related config and variable (#66803)
I don't know when we removed sandbox but this datum doesn't exist anymore and this var is unused Also the config does nothing anymore so might as well throw that out |
||
|
|
baeb120232 |
Add config entries for PR_ANNOUNCEMENTS_PER_ROUND and STATION_GOAL_BUDGET (#64368)
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com> |
||
|
+25Watermelon914GitHubWatermelon914tralezabGhilkertgstation-servergbfreeSealed101ChangelogsJohn WillardvincentiusvinorangesSeth SchererJeremiahAzarakRandomGamer123LemonInTheDarkKyleraceike709IamgoofballMrMelbertPepsilawnAnturKMothblocksSuperNovaa41GoldenAlpharexFikousan7890MMMiraclesKrysonismAziz ChynalievTastyfishMooshimicarshalashRyll Ryll |
8fd85e9666 |
[MDB IGNORE] BIDDLE TRAITORS - Adds progression traitors. Refactors uplink code in its entirety (#63588)
Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com> Co-authored-by: tralezab <40974010+tralezab@users.noreply.github.com> Co-authored-by: Ghilker <42839747+Ghilker@users.noreply.github.com> Co-authored-by: tgstation-server <tgstation-server@tgstation13.org> Co-authored-by: gbfree <guillaumebfree@gmail.com> Co-authored-by: Sealed101 <75863639+Sealed101@users.noreply.github.com> Co-authored-by: Changelogs <action@github.com> Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com> Co-authored-by: vincentiusvin <54709710+vincentiusvin@users.noreply.github.com> Co-authored-by: oranges <email@oranges.net.nz> Co-authored-by: Seth Scherer <supernovaa41@gmx.com> Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com> Co-authored-by: Azarak <azarak10@gmail.com> Co-authored-by: RandomGamer123 <31096837+RandomGamer123@users.noreply.github.com> Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> Co-authored-by: Kylerace <kylerlumpkin1@gmail.com> Co-authored-by: ike709 <ike709@users.noreply.github.com> Co-authored-by: Iamgoofball <iamgoofball@gmail.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: Pepsilawn <reisenrui@gmail.com> Co-authored-by: AnturK <AnturK@users.noreply.github.com> Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> Co-authored-by: SuperNovaa41 <supernovaa41@protonmail.com> Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com> Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com> Co-authored-by: san7890 <34697715+san7890@users.noreply.github.com> Co-authored-by: MMMiracles <lolaccount1@hotmail.com> Co-authored-by: Krysonism <49783092+Krysonism@users.noreply.github.com> Co-authored-by: Aziz Chynaliev <azizonkg@gmail.com> Co-authored-by: Tastyfish <crazychris32@gmail.com> Co-authored-by: Mooshimi <85910816+Mooshimi@users.noreply.github.com> Co-authored-by: carshalash <carshalash@gmail.com> Co-authored-by: Ryll Ryll <3589655+Ryll-Ryll@users.noreply.github.com> |
||
|
John WillardandGitHub
|
2834383245 |
Makes all default job titles, defines. (#63357)
Jesus christ we were just waiting for someone to misspell something eh? |
||
|
AzarakandGitHub
|
680ca7d3b9 |
Field of View and Blindness improvements [bounty + upstream push] (#63312)
About The Pull Request I have received exemption from the freeze by Oranges. This PR was originally done for Skyrat-tg, as a bounty. Oranges took interest and Skyrat people approved taking it upstream so I did. (original PR Skyrat-SS13/Skyrat-tg#9912 ) Features: This PR adds "field of view" mechanics, which by default don't do anything. Once you pick up and wear a gas mask you'll notice a cone behind you. That cone will hide all mobs, projectiles and projectile effects. HOWEVER... hidden things in the cone (or for people who are blind or nearsighted) will play a visual effect. The fov cone shadow density can be adjusted Technicalities: Originally a component, but by Watermelon's advice I have made this a datumized behaviour instead. (semi-component) This way it is faster, less memory use etc. Once again a component People have native fov, which can be enabled by a config, by default it's off. (or by an admin verb) People have fov traits, which add the fov impairings to you, gas masks do that now. All clothes have a support for possibly applying them. Moves all things that should be hidden onto a new plane which is just above GAME_PLANE, that was we can efficiently filter them out of clients views. Being dead or extending your eye view (xenobio console) will disable the FOV mask. This PR was brought to you by Skyrat paying me aswell as rotational mathematics Why It's Good For The Game Oranges approves so it's good. Changelog cl add: Gas Masks now limit your field of view add: Added field of view mechanics. It's darkness can be tweaked by a pref add: Blind, nearsighted and fov-limited people will now see sounds as visual effects. /cl |
||
|
TimberpoesandGitHub
|
025018014d |
Tackles various problems with keyed_list config entries, fixing broken roundstart races and more! (#62359)
While helping RaveRadbury debug some issues with enabling Halloween species early via the brute force method of enabling them in the config rather than the gentleman's solution of testmerging a PR that changes the Halloween date, we discovered something dreadful.
Cloth golems cannot be enabled! Infact, any species with a space in the ID cannot be enabled.
It uses the splitter despite VALUE_MODE_FLAG being set. So a key entry like ROUNDSTART_RACES cloth golem would get parsed as cloth = golem, then entered into the config as cloth = TRUE
NEW AND IMPROVED PART HERE
I've re-written how keyed_list config entries are parsed, splitting it into a number of procs to do some discrete block of logic.
Based on feedback from MSO, he expected that VALUE_MODE_FLAG keyed_list entries could have elements overridden. However, this functionality was not present in the code.
I have implemented it. We now support 3 methods of setting VALUE_MODE_FLAGS.
Implicitly enable the config entry: CONFIG_ENTRY config_key_goes_here
Explicitly enable the config entry: CONFIG_ENTRY config_key_goes_here 1
Explicitly disable the config entry: CONFIG_ENTRY config_key_goes_here 0
There have been functionality changes too. Previously, everything before the first splitter was the key and everything after was the value. However, in ambiguous config entries (Such as ROUNDSTART_RACES cloth golem 0) it would be unclear if the intent was (cloth, golem 0) or (cloth golem, 0) or indeed if the intent was (cloth golem 0, 1).
As a result, there is now the following paradigm in place: Everything after the LAST splitter is the value, everything before is the key and a log_config warning is now given explaining the problem and showing how it was resolved.
[2021-10-27 19:48:12.840] WARNING: Multiple splitter characters (" ") found. Using "cloth golem" as config key and "1" as config value.
This warning will trigger if multiple splitters are present for any keyed_list config entry, and will trigger on implicit VALUE_MODE_FLAGS entries that have splitters. The example above is it triggering on ROUNDSTART_RACES cloth golem - It has detected that there is potential ambiguity between (cloth, golem) or (cloth golem, 1), has picked a sensible option for the data type and has warned about it.
The intent is that no config entry should be ambiguous. It should be clear what is key and what is value when dealing with keyed_list config entries.
There's probably more work to do on other config entries to bring them up to this standard, but this is the thing I'm hitting in this PR.
Similarly, I have improved the validation aspect of keyed_list config entries with additional logging in general.
[2021-10-27 19:47:53.135] ERROR: Invalid KEY_MODE_TYPE typepath. Is not a valid typepath: /mob/living/carbon/monkey
I have added a unit test to make sure species IDs do not contain splitters from the two keyed_list subtypes relating to species.
I have added sanity checking to the race config subtypes since we have a big dick global list of all races sorted by ID, so a race not existing will fail validation and output a meaningful config log entry.
I have removed /datum/config_entry/keyed_list/probability from the code as it is unused with the removal of all game modes except Dynamic.
The config change necessitated the renaming of all golem species IDs. Doing so and renaming the clothgolem.ts file to match has fixed the broken cloth golem page too.
|