mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-11 18:22:14 +00:00
4f2b55d05c59cd40d0451f958fd8583c5e909ae2
507 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
MrMelbert
|
890855b1ef |
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". /🆑 |
||
Jacquerel
|
d3a5cd5787 |
Increases logging for candidate polls (#91590)
## About The Pull Request The game will now log when someone signs up or removes their candidacy for ghost polls for roles. This also fixes a runtime I experienced while testing it and running pirates with no candidates signed up, IDK if it had any effect but it's possible the runtime was causing the ship not to spawn. ## Why It's Good For The Game Mostly just that I saw admins requesting this on several recent occasions. It's already possible to dig up some of this information through the existing logs but it's a bit of a pain. ## Changelog 🆑 admin: Additional logging for when people sign up for ghost roles. /🆑 |
||
John Willard
|
2a79d6424e |
Removes widescreen config (#91419)
19x15 forever, or 15x15 if you're non widescreen user. Idek why this is a config |
||
|
John Willard
|
c5d84a2b20 |
Moves info buttons to the Escape menu (#91234)
This is my second contribution to the move towards removing the stat panel (first one being https://github.com/tgstation/tgstation/pull/90572 ) This moves the info buttons at the top right of the game's screen (Changelog, Rules, Wiki, etc) to the Escape menu, except for Fullscreen which is now a pref instead. This means you can set Fullscreen to be on permanently and every launch will automatically fullscreen you (the viewport will be a little off because it only fixes it once initialization is complete). This follows through rounds and auto updates if you set your game to fullscreen with the OOC button or F11, so players will learn about the pref after playing a round with fullscreen enabled. What the game now looks like be a newscaster https://github.com/user-attachments/assets/7871a226-1e0b-410d-a690-88f3616bebb0 This is something I wanted to do since the Esc menu was added but just never got around to it, but here it is. These buttons don't warrant being in the player's face 24/7 and since we've want to remove the stat panel and this has to be somewhere, I thought it would be a better fit in the Escape menu. It helps make the Esc menu the tool players use to access their OOC tools and overall I think improves the appearance of the game's screen to something more like an actual game would look like, especially when our comparison is SS14. 🆑 qol: Info buttons previously at the top right of your screen (Changelog, wiki, forums) is now in the Escape menu. qol: Fullscreen is now a preferences and will follow you through rounds. /🆑 |
||
Bloop
|
655b66bdd0 |
Adds automatic GAGS icon generation for mapping and the loadout menu (#90940)
Revival of https://github.com/tgstation/tgstation/pull/86482, which is even more doable now that we have rustg iconforge generation. What this PR does: - Sets up every single GAGS icon in the game to have their own preview icon autogenerated during compile. This is configurable to not run during live. The icons are created in `icons/map_icons/..` - This also has the side effect of providing accurate GAGS icons for things like the loadout menu. No more having to create your own previews.  <details><summary>Mappers rejoice!</summary>   </details> <details><summary>Uses iconforge so it does not take up much time during init</summary>  </details> --- this still applies: Note for Spriters: After you've assigned the correct values to vars, you must run the game through init on your local machine and commit the changes to the map icon dmi files. Unit tests should catch all cases of forgetting to assign the correct vars, or not running through init. Note for Server Operators: In order to not generate these icons on live I've added a new config entry which should be disabled on live called GENERATE_ASSETS_IN_INIT in the config.txt No more error icons in SDMM and loadout. 🆑 refactor: preview icons for greyscale items are now automatically generated, meaning you can see GAGS as they actually appear ingame while mapping or viewing the loadout menu. /🆑 --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> |
||
|
John Willard
|
df10c57593 |
webmap is now in maps.txt instead of a config entry (#90821)
## About The Pull Request Currently the button to open a map in webmap is tied to a config entry, which would then take the name of the map being played and get the link to that, however for cases like new/tested/admin uploaded maps where there is no webmap available, this would still have a link to a url that doesn't exist. Instead, we'll make the webmap link be in ``maps.txt``, same as feedbacklink. ## Why It's Good For The Game Explained in the about section, this prevents webmaps appearing for maps that aren't supposed to have a webmap link available. ## Changelog Nothing player-facing, webmaps aren't currently used (afaik) currently cause they're broken for tg codebases. |
||
|
John Willard
|
ea28a87ca8 |
Adds map feedback thread support (AI stat panel buff) (#90506)
This PR started with the idea of adding support for map feedback threads, which I added to the roundend report, escape menu, and stat panel. To do this though I had to make pretty annoying changes to the stat panel and had to touch every single time something to the stat panel was added, so since we now have a way to have links in the stat panel I thought of taking full advantage of it and add some QOL. AIs can now track their borgs by clicking their status on the stat panel https://github.com/user-attachments/assets/1789dc46-5d12-48e9-bb8d-d3278aa19639 With Melbert's comment, I added another stat panel entry that directs you to the Webmap page, which currently seems to be a little messed up (https://github.com/AffectedArc07/SS13WebMap/issues/41 & https://github.com/AffectedArc07/SS13WebMap/issues/42) but if they get fixed this would be a swag asf feature Feedback threads was a suggestion from a player and is fully in control of admins as an optional thing, and while we still have stat panel I think it's nice to be able to take advantage of its features. 🆑 admin: Admins can now link a URL for maps, used to give feedback on said maps. Accessible through the roundend report, escape menu, and stat panel. qol: AIs can track their borgs by clicking on them in the stat panel. qol: You can now directly go to the webmap of maps from the stat panel (assuming it's set in config). /🆑 |
||
|
John Willard
|
d9c58ac82e |
Configurable events (removes mult config) (#90659)
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). 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!  🆑 config: Removed event time/weight multipliers, now all events vars are editable in config. /🆑 --------- Co-authored-by: CRITAWAKETS <sebastienracicot@hotmail.com> |
||
Nick
|
5ee12a8d33 | Adds the ability to link forum accounts (#90441) | ||
nevimer
|
12d995aeea |
Squashed commit of the following:
commit cb550ab79badae3ffd493dcee24d96f7ad146ed6 Merge: 732416f01d8 |
||
Waterpig
|
753d8e5ba4 | Merge branch 'master' of https://github.com/tgstation/tgstation into upstream-25-04a | ||
Jordan Dominion
|
a834a92ed6 | Add an event to config reloading that can be used to trigger a config sync (#90329) | ||
|
Jordan Dominion
|
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. |
||
LemonInTheDark
|
3b9d4cb78c |
Relative Config $imports (#89418)
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may not be viewable. --> <!-- You can view Contributing.MD for a detailed description of the pull request process. --> ## About The Pull Request When you import a config file inside a subdirectory, the config loader will now look IN that subdirectory, instead of exiting out to the parent folder. As a consequence, adds support for ".." to our deduplication system to avoid infinite loops due to headmin brain. ## Why It's Good For The Game jannies are on some shit wanna make their lives a bit nicer Note: I am testing on windows and also have only a loose grasp of how linux works, might fuck up in that environment idk ## Changelog <!-- If your PR modifies aspects of the game that can be concretely observed by players or admins you should add a changelog. If your change does NOT meet this description, remove this section. Be sure to properly mark your PRs to prevent unnecessary GBP loss. You can read up on GBP and its effects on PRs in the tgstation guides for contributors. Please note that maintainers freely reserve the right to remove and add tags should they deem it appropriate. You can attempt to finagle the system all you want, but it's best to shoot for clear communication right off the bat. --> 🆑 config: the config loader now supports relatively pathed imports (importing a file inside a subfolder now acts as if you were IN that subfolder) /🆑 <!-- Both 🆑's are required for the changelog to work! You can put your name to the right of the first 🆑 if you want to overwrite your GitHub username as author ingame. --> <!-- You can use multiple of the same prefix (they're only used for the icon ingame) and delete the unneeded ones. Despite some of the tags, changelogs should generally represent how a player might be affected by the changes rather than a summary of the PR's contents. --> |
||
Kashargul
|
09f01e3bb3 |
Fix config FPS/ Ticklag auto handling (#89792)
FPS / Ticklag should be independent configs, but due to the use of `trim()` at |
||
itsmeow
|
9ebcabb077 |
IconForge: rust-g Spritesheet Generation (#89478)
Replaces the asset subsystem's spritesheet generator with a rust-based implementation (https://github.com/tgstation/rust-g/pull/160). This is a rough port of https://github.com/BeeStation/BeeStation-Hornet/pull/10404, but it includes fixes for some cases I didn't catch that apply on TG. (FWIW we've been using this system on prod for over a year and encountered no major issues.)  `/datum/asset/spritesheet_batched`: A version of the spritesheet system that collects a list of `/datum/universal_icon`s and sends them off to rustg asynchronously, and the generation also runs on another thread, so the game doesn't block during realize_spritesheet. The rust generation is about 10x faster when it comes to actual icon generation, but the biggest perk of the batched spritesheets is the caching system. This PR notably does not convert a few things to the new spritesheet generator. - Species and antagonist icons in the preferences view because they use getFlatIcon ~~which can't be converted to universal icons~~. - Yes, this is still a *massive* cost to init, unfortunately. On Bee, I actually enabled the 'legacy' cache on prod and development, which you can see in my PR. That's why I added the 'clear cache' verb and the `unregister()` procs, because it can force a regeneration at runtime. I decided not to port this, since I think it would be detrimental to the large amount of contributors here. - It is *technically* possible to port parts of this to the uni_icon system by making a uni_icon version of getFlatIcon. However, some overlays use runtime-generated icons which are ~~completely unparseable to IconForge, since they're stored in the RSC and don't exist as files anywhere~~. This is most noticeable with things like hair (which blend additively with the hair mask on the server, thus making them invisible to `get_flat_uni_icon`). It also doesn't help that species and antag icons will still need to generate a bunch of dummies and delete them to even verify cache validity. - It is actually possible to write the RSC icons to the filesystem (using fcopy) and reference them in IconForge. However, I'm going to wait on doing this until I port my GAGS implementation because it requires GAGS to exist on the filesystem as well. IconForge generates a cache based on the set of icons used, all transform operations applied, and the source DMIs of each icon used within the spritesheet. It can compare the hashes and invalidate the cache automatically if any of these change. This means we can enable caching on development, and have absolutely no downsides, because if anything changes, the cache invalidates itself. The caching has a mean cost of ~5ms and saves a lot of time compared to generating the spritesheet, even with rust's faster generation. The main downside is that the cache still requires building the list of icons and their transforms, then json encoding it to send to rustg. Here's an abbreviated example of a cache JSON. All of these need to match for the cache to be valid. `input_hash` contains the transform definitions for all the sprites in the spritesheet, so if the input to iconforge changes, that hash catches it. The `sizes` and `sprites` are loaded into DM. ```json { "input_hash": "99f1bc67d590e000", "dmi_hashes": { "icons/ui/achievements/achievements.dmi": "771200c75da11c62" }, "sizes": [ "76x76" ], "sprites": { "achievement-rustascend": { "size_id": "76x76", "position": 1 } }, "rustg_version": "3.6.0", "dm_version": 1 } ``` Universal icons are just a collection of DMI, Icon State, and any icon transformation procs you apply (blends, crops, scales). They can be convered to DM icons via `to_icon()`. I've included an implementation of GAGS that produces universal icons, allowing GAGS items to be converted into them. IconForge can read universal icons and add them to spritesheets. It's basically just a wrapper that reimplements BYOND icon procs. Converts some uses of md5asfile within legacy spritesheets to use rustg_hash_file instead, improving the performance of their generation. Fixes lizard body markings not showing in previews, and re-adds eyes to the ethereal color preview. This is a side effect of IconForge having *much* better error handling than DM icon procs. Invalid stuff that gets passed around will error instead of silently doing nothing. Changes the CSS used in legacy spritesheet generation to split `background: url(...) no-repeat` into separate props. This is necessary for WebView2, as IE treats these properties differently - adding `background-color` to an icon object (as seen in the R&D console) won't work if you don't split these out. Deletes unused spritesheets and their associated icons (condiments spritesheet, old PDA spritesheet) If you press "Character Setup", the 10-13sec of lag is now approximately 0.5-2 seconds. Tracy profile showing the time spent on get_asset_datum. I pressed the preferences button during init on both branches. Do note that this was ran with a smart cache HIT, so no generation occurred.  Much lower worst-case for /datum/asset/New (which includes `create_spritesheets()` and `register()`)  Here's a look at the internal costs from rustg - as you can see `generate_spritesheet()` is very fast:  **Before**  **After**  🆑 fix: Fixed lizard body markings and ethereal feature previews in the preference menu missing some overlays. refactor: Optimized spritesheet asset generation greatly using rustg IconForge, greatly reducing post-initialization lag as well as reducing init times and saving server computation. config: Added 'smart' asset caching, for batched rustg IconForge spritesheets. It is persistent and suitable for use on local, with automatic invalidation. add: Added admin verbs - Debug -> Clear Smart/Legacy Asset Cache for spritesheets. fix: Fixed R&D console icons breaking on WebView2/516 /🆑 |
||
Y0SH1M4S73R
|
f3ac412f69 |
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> |
||
|
Jacquerel
|
53248581a3 |
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. /🆑 |
||
Jackraxxus
|
95081b7acd |
Adds a Config for Auto-Deadminning on Ready Up and Latejoining (#89522)
## About The Pull Request Fixes #89458 Adds a config for auto-deadminning admins who ready up before the round starts, or click join game after. The deadminning happens as soon as the button is pressed, not when a job is selected or the round starts. I figure it's better to do it straight away since both have opportunities for metainfo to be posted in admin chat. Before there's admins messing with dynamic config / plotting events etc. and during the round there's basically everything that gets posted to admin logs. I've had to add a typecheck to the auto_deadmin proc, since the lobby menu technically happens on the centcom Z-level, and there's a pref for ignoring deadminning on centcom Z, so it checks to see if the admin is a new player mob. Changed the old config from auto_deadmin_player to auto_deadmin_always to make it less deceptive. Was suggested a pref could be added to do this. I can do that if people want it maybe, but it's not in this PR at the time of posting it. Is now a pref <img src="https://i.ibb.co/211sBMYd/Deadmin-Prefs1.png"> <img src="https://i.ibb.co/r20Srbw4/Deadmin-Prefs2.png"> I dunno if the latejoin proccall is in the right spot in the click sequence thing I can move it if people want. ## Why It's Good For The Game Admins spawning themselves on station is very important for both shenanigans and troubleshooting. It's annoying to have to click readmin every time and I'm too lazy to figure out how to perms escalate my way into disabling that config every round (Though I have tried). This PR is marginally more likely to convince Timber to turn that off than cussing him out in adminbus. ## Changelog 🆑 admin: Added a new config to force admins to deadmin when readying up or latejoining the round. /🆑 |
||
Ivory
|
c388cfcecb |
[NO GBP] Fix channel announcements not working with multiple values (#89524)
forgot to remove the defaults, with those the configs get interpreted as one big string instead of a list |
||
|
Ivory
|
0379638cb6 |
Support sending channel announcements to multiple channel tags (#89462)
previous system was weird, you had to add a comma separated list in the channel tag in TGS itself. this is much more intuitive. also it should not break older configs 🆑 config: Added support for multiple chat channel configs for channel announcements. /🆑 |
||
|
Jacquerel
|
434e4e435e |
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. /🆑 |
||
|
LemonInTheDark
|
96ee8fd2a5 |
Relative Config $imports (#89418)
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may not be viewable. --> <!-- You can view Contributing.MD for a detailed description of the pull request process. --> ## About The Pull Request When you import a config file inside a subdirectory, the config loader will now look IN that subdirectory, instead of exiting out to the parent folder. As a consequence, adds support for ".." to our deduplication system to avoid infinite loops due to headmin brain. ## Why It's Good For The Game jannies are on some shit wanna make their lives a bit nicer Note: I am testing on windows and also have only a loose grasp of how linux works, might fuck up in that environment idk ## Changelog <!-- If your PR modifies aspects of the game that can be concretely observed by players or admins you should add a changelog. If your change does NOT meet this description, remove this section. Be sure to properly mark your PRs to prevent unnecessary GBP loss. You can read up on GBP and its effects on PRs in the tgstation guides for contributors. Please note that maintainers freely reserve the right to remove and add tags should they deem it appropriate. You can attempt to finagle the system all you want, but it's best to shoot for clear communication right off the bat. --> 🆑 config: the config loader now supports relatively pathed imports (importing a file inside a subfolder now acts as if you were IN that subfolder) /🆑 <!-- Both 🆑's are required for the changelog to work! You can put your name to the right of the first 🆑 if you want to overwrite your GitHub username as author ingame. --> <!-- You can use multiple of the same prefix (they're only used for the icon ingame) and delete the unneeded ones. Despite some of the tags, changelogs should generally represent how a player might be affected by the changes rather than a summary of the PR's contents. --> |
||
|
Kashargul
|
5168862d61 |
Fix config FPS/ Ticklag auto handling (#89792)
FPS / Ticklag should be independent configs, but due to the use of `trim()` at |
||
|
itsmeow
|
cc335e7e9e |
IconForge: rust-g Spritesheet Generation (#89478)
## About The Pull Request Replaces the asset subsystem's spritesheet generator with a rust-based implementation (https://github.com/tgstation/rust-g/pull/160). This is a rough port of https://github.com/BeeStation/BeeStation-Hornet/pull/10404, but it includes fixes for some cases I didn't catch that apply on TG. (FWIW we've been using this system on prod for over a year and encountered no major issues.) ### TG MAINTAINER NOTE  ### Batched Spritesheets `/datum/asset/spritesheet_batched`: A version of the spritesheet system that collects a list of `/datum/universal_icon`s and sends them off to rustg asynchronously, and the generation also runs on another thread, so the game doesn't block during realize_spritesheet. The rust generation is about 10x faster when it comes to actual icon generation, but the biggest perk of the batched spritesheets is the caching system. This PR notably does not convert a few things to the new spritesheet generator. - Species and antagonist icons in the preferences view because they use getFlatIcon ~~which can't be converted to universal icons~~. - Yes, this is still a *massive* cost to init, unfortunately. On Bee, I actually enabled the 'legacy' cache on prod and development, which you can see in my PR. That's why I added the 'clear cache' verb and the `unregister()` procs, because it can force a regeneration at runtime. I decided not to port this, since I think it would be detrimental to the large amount of contributors here. - It is *technically* possible to port parts of this to the uni_icon system by making a uni_icon version of getFlatIcon. However, some overlays use runtime-generated icons which are ~~completely unparseable to IconForge, since they're stored in the RSC and don't exist as files anywhere~~. This is most noticeable with things like hair (which blend additively with the hair mask on the server, thus making them invisible to `get_flat_uni_icon`). It also doesn't help that species and antag icons will still need to generate a bunch of dummies and delete them to even verify cache validity. - It is actually possible to write the RSC icons to the filesystem (using fcopy) and reference them in IconForge. However, I'm going to wait on doing this until I port my GAGS implementation because it requires GAGS to exist on the filesystem as well. #### Caching IconForge generates a cache based on the set of icons used, all transform operations applied, and the source DMIs of each icon used within the spritesheet. It can compare the hashes and invalidate the cache automatically if any of these change. This means we can enable caching on development, and have absolutely no downsides, because if anything changes, the cache invalidates itself. The caching has a mean cost of ~5ms and saves a lot of time compared to generating the spritesheet, even with rust's faster generation. The main downside is that the cache still requires building the list of icons and their transforms, then json encoding it to send to rustg. Here's an abbreviated example of a cache JSON. All of these need to match for the cache to be valid. `input_hash` contains the transform definitions for all the sprites in the spritesheet, so if the input to iconforge changes, that hash catches it. The `sizes` and `sprites` are loaded into DM. ```json { "input_hash": "99f1bc67d590e000", "dmi_hashes": { "icons/ui/achievements/achievements.dmi": "771200c75da11c62" }, "sizes": [ "76x76" ], "sprites": { "achievement-rustascend": { "size_id": "76x76", "position": 1 } }, "rustg_version": "3.6.0", "dm_version": 1 } ``` ### Universal Icons Universal icons are just a collection of DMI, Icon State, and any icon transformation procs you apply (blends, crops, scales). They can be convered to DM icons via `to_icon()`. I've included an implementation of GAGS that produces universal icons, allowing GAGS items to be converted into them. IconForge can read universal icons and add them to spritesheets. It's basically just a wrapper that reimplements BYOND icon procs. ### Other Stuff Converts some uses of md5asfile within legacy spritesheets to use rustg_hash_file instead, improving the performance of their generation. Fixes lizard body markings not showing in previews, and re-adds eyes to the ethereal color preview. This is a side effect of IconForge having *much* better error handling than DM icon procs. Invalid stuff that gets passed around will error instead of silently doing nothing. Changes the CSS used in legacy spritesheet generation to split `background: url(...) no-repeat` into separate props. This is necessary for WebView2, as IE treats these properties differently - adding `background-color` to an icon object (as seen in the R&D console) won't work if you don't split these out. Deletes unused spritesheets and their associated icons (condiments spritesheet, old PDA spritesheet) ## Why It's Good For The Game If you press "Character Setup", the 10-13sec of lag is now approximately 0.5-2 seconds. Tracy profile showing the time spent on get_asset_datum. I pressed the preferences button during init on both branches. Do note that this was ran with a smart cache HIT, so no generation occurred.  Much lower worst-case for /datum/asset/New (which includes `create_spritesheets()` and `register()`)  Here's a look at the internal costs from rustg - as you can see `generate_spritesheet()` is very fast:  ### Comparison for a single spritesheet - chat spritesheet: **Before**  **After**  ## Changelog 🆑 fix: Fixed lizard body markings and ethereal feature previews in the preference menu missing some overlays. refactor: Optimized spritesheet asset generation greatly using rustg IconForge, greatly reducing post-initialization lag as well as reducing init times and saving server computation. config: Added 'smart' asset caching, for batched rustg IconForge spritesheets. It is persistent and suitable for use on local, with automatic invalidation. add: Added admin verbs - Debug -> Clear Smart/Legacy Asset Cache for spritesheets. fix: Fixed R&D console icons breaking on WebView2/516 /🆑 |
||
|
Y0SH1M4S73R
|
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> |
||
|
Jacquerel
|
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. /🆑 |
||
|
Jackraxxus
|
0ec9ab3a17 |
Adds a Config for Auto-Deadminning on Ready Up and Latejoining (#89522)
## About The Pull Request Fixes #89458 Adds a config for auto-deadminning admins who ready up before the round starts, or click join game after. The deadminning happens as soon as the button is pressed, not when a job is selected or the round starts. I figure it's better to do it straight away since both have opportunities for metainfo to be posted in admin chat. Before there's admins messing with dynamic config / plotting events etc. and during the round there's basically everything that gets posted to admin logs. I've had to add a typecheck to the auto_deadmin proc, since the lobby menu technically happens on the centcom Z-level, and there's a pref for ignoring deadminning on centcom Z, so it checks to see if the admin is a new player mob. Changed the old config from auto_deadmin_player to auto_deadmin_always to make it less deceptive. Was suggested a pref could be added to do this. I can do that if people want it maybe, but it's not in this PR at the time of posting it. Is now a pref <img src="https://i.ibb.co/211sBMYd/Deadmin-Prefs1.png"> <img src="https://i.ibb.co/r20Srbw4/Deadmin-Prefs2.png"> I dunno if the latejoin proccall is in the right spot in the click sequence thing I can move it if people want. ## Why It's Good For The Game Admins spawning themselves on station is very important for both shenanigans and troubleshooting. It's annoying to have to click readmin every time and I'm too lazy to figure out how to perms escalate my way into disabling that config every round (Though I have tried). This PR is marginally more likely to convince Timber to turn that off than cussing him out in adminbus. ## Changelog 🆑 admin: Added a new config to force admins to deadmin when readying up or latejoining the round. /🆑 |
||
Majkl-J
|
b6b8306fda | Merge branch 'master' of https://github.com/tgstation/tgstation into upstream-25-02a | ||
|
Ivory
|
fe656734fb |
[NO GBP] Fix channel announcements not working with multiple values (#89524)
forgot to remove the defaults, with those the configs get interpreted as one big string instead of a list |
||
|
Ivory
|
ecdf8bc9c1 |
Support sending channel announcements to multiple channel tags (#89462)
previous system was weird, you had to add a comma separated list in the channel tag in TGS itself. this is much more intuitive. also it should not break older configs 🆑 config: Added support for multiple chat channel configs for channel announcements. /🆑 |
||
|
Jacquerel
|
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. /🆑 |
||
|
Jordan Dominion
|
88f9d9ca49 |
Separate the server linking behavior from the displayed TGS address (#89421)
DDoS prevention stuff |
||
The Sharkening
|
06f2f5b7ec |
Integrates vocal barks with TTS (#2811)
- Intigrates vocal barks into TTS. - If TTS voice is None, broadcasts vocal barks to everyone else. 🆑 add: TTS compatability with vocal barks /🆑 |
||
Penelope Haze
|
4c2a76ede3 |
Fix a large number of typos (#89254)
Fixes a very large number of typos. A few of these fixes also extend to variable names, but only the really egregious ones like "concious". |
||
Iamgoofball
|
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. /🆑 |
||
grungussuss
|
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. /🆑 |
||
Lucy
|
9592b333e2 |
byond-tracy additions and refactors (#87067)
## About The Pull Request This adds plenty of useful stuff regarding byond-tracy, altho mostly focused on the [Paradise fork](https://github.com/ParadiseSS13/byond-tracy). - Adds two new config options **(THEY ARE DISABLED BY DEFAULT)** - `ALLOW_TRACY_START` gives admins with +DEBUG the "Run Tracy Now" verb, which will allow them to start profiling with byond-tracy mid-round. - `ALLOW_TRACY_QUEUE` gives admins with +DEBUG the "Toggle Tracy Next Round" verb, which will initialize byond-tracy during world init the next round (in the same way as passing `-params tracy` or defining `USE_BYOND_TRACY`) - If byond-tracy fails to initialize, the error will be logged and available to view for the whole round. - If `MC_TAB_TRACY_INFO` is defined, information about byond-tracy now appears in the MC tab - if it's running or not, if it errored (and what the error is), why it's running, if its queued for next round, etc. - byond-tracy is now properly shut down when the world shuts down/reboots, minimizing the risk of data loss or crashing - More info regarding byond-tracy init is sent to `world.log` ## Why It's Good For The Game Profiling is super helpful, and this should make things quite easier ## Changelog No user-facing changes |
||
Ilán Mori
|
9facb9914a |
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> # Conflicts: # config/game_options.txt # config/jobconfig.toml |
||
LT3
|
8026188a38 |
Map vote uses simple, not weighted random / show map vote calculation and carryover info (#2285)
## About The Pull Request Un-hides the map vote result calculation, showing the tallies and the carryover percentage. Closes https://github.com/Bubberstation/Bubberstation/issues/2284 Switches vote calc method to simple instead of weighted random ## Proof Of Testing <details> <summary>Screenshots/Videos</summary>  </details> ## Changelog 🆑 LT3 qol: You can now see the tallies used to calculate map votes /🆑 |
||
CliffracerX
|
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 /🆑 |
||
|
Majkl-J
|
e59d8ba64b | Merge commit '179a607a90ad7ec62bdaff4e6fe72af60ee56442' of https://github.com/tgstation/tgstation into upstream-24-10b | ||
|
Waterpig
|
bb70889f6e |
TG Upstream Part 1
3591 individual conflicts Update build.js Update install_node.sh Update byond.js oh my fucking god hat slow huh holy shit we all fall down 2 more I missed 2900 individual conflicts 2700 Individual conflicts replaces yarn file with tg version, bumping us down to 2200-ish Down to 2000 individual conflicts 140 down mmm aaaaaaaaaaaaaaaaaaa not yt 575 soon 900 individual conflicts 600 individual conflicts, 121 file conflicts im not okay 160 across 19 files 29 in 4 files 0 conflicts, compiletime fix time some minor incap stuff missed ticks weird dupe definition stuff missed ticks 2 incap fixes undefs and pie fix Radio update and some extra minor stuff returns a single override no more dupe definitions, 175 compiletime errors Unticked file fix sound and emote stuff honk and more radio stuff |
||
|
Ilán Mori
|
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> |
||
Zephyr
|
0ef5c3d049 |
Persistent Map Vote Tallies (#86788)
## About The Pull Request Changes map votes to be based on a persistent tally count. Tallies for maps are cached between rounds and are added to by map votes. When a map is chosen, and it wasn't the only valid one, the tallies for said chosen map will be reset. Refactors map vote handling and moves it from SSmapping to SSmap_vote. Rock the Vote has been removed as a result of this refactor. ## Why It's Good For The Game Makes it more likely that all maps will be played over the course of a server instead of always being truly random. Removes some clutter off of SSmapping. 🆑 refactor: Map Votes are now carried over between rounds. When a map vote is actually a contest, the winning map will have its votes reset. /🆑 |
||
Jerry
|
088409bbe3 |
Fix guide books that rely on the wiki (#86891)
## About The Pull Request This pull request aims to fix the wiki manuals. Currently the wiki manuals just show "You start skimming through the manual..." because of a bad link (http://www.tgstation13.org/wiki instead of http://tgstation13.org/wiki) which is fixed with this PR, but the issue does not end there. Because BYOND uses trident for its `browse()` function, a lot of Javascript and HTML elements do not function properly, disallowing the removal or blocking of hyperlinks which break the book entirely if they are clicked. Therefore, as a temporary solution (until BYOND 516 is released with webview2) when the user opens a book they are prompted with the following:  Although not the best solution, it makes the books have a function again and are usable. Fixes https://github.com/tgstation/tgstation/issues/77315. ## Why It's Good For The Game Makes books work again so new players can use them to be guided to the wiki resources. ## Changelog 🆑 fix: fix wiki manuals by making them open wiki page on browser /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
Jerry
|
6a654b1612 |
Fix link for rules button (#86860)
## About The Pull Request This pull request fixes the link you get redirected to when you click the "Rules" button on the top right of the game. Before it redirected to http://www.tgstation13.org/wiki/Rules but the correct link is http://tgstation13.org/wiki/rules (the www part is the problem). ## Why It's Good For The Game Makes the rules button direct you to the correct link, making it easier for someone to view the rules of the server. ## Changelog 🆑 fix: fixed link for the rules button /🆑 |
||
|
Waterpig
|
4c4930c71d | Merge branch 'master' of https://github.com/tgstation/tgstation into pulls-tg-to-fix-shit | ||
SkyratBot
|
6a418150e8 |
[MIRROR] Spelling and Grammar Fixes (#29499)
* Spelling and Grammar Fixes * they dont understand --------- Co-authored-by: klorpa <30924131+klorpa@users.noreply.github.com> Co-authored-by: projectkepler-RU <99981766+projectkepler-ru@users.noreply.github.com> |
||
klorpa
|
d2c7806047 |
Spelling and Grammar Fixes (#85992)
## About The Pull Request Fixes several errors to spelling, grammar, and punctuation. ## Why It's Good For The Game ## Changelog 🆑 spellcheck: fixed a few typos /🆑 |
