mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-08-23 21:18:37 +01:00
master
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
15baf7873a |
Offsite Deathrattle Implants and Repathed Kheiral Cuffs (#94209)
## About The Pull Request Updates subdermal implants so that they have `implant_info` and `implant_lore` variables instead of one unchanging `get_info()`. Also rewrites/updates/tweaks/etc. lore for every implant that had get_info() blocks. Makes beacon implants (the ones you teleport onto) turn off (hide themselves on prisoner management consoles) after ten minutes, matching the tracking implant's functionality. Deathrattle implants are now `allow_multiple = TRUE`, so you can have multiple deathrattles implanted. Reworked the implant pad's UI to have collapsible sections for implant info, implant lore, and also have buttons for configuring deathrattle implants. Adds a box of expeditionary deathrattle implants to the mining vendor. For 900 points (585 points if delivered), you receive a box containing 5 expeditionary deathrattle implants, which **ONLY ALERT TO DEATHS IN MINING WASTELAND AREAS (e.g. not ruins, not space, not station) (this is important)**, an implanter, and an implant pad. The intended workflow is that you initialize one deathrattle implant, use that network for all the other deathrattles, and implant yourself, your mining buddies, your QM, and a paramedic, maybe. However since they start unset you could theoretically make one really big deathrattle network. Good luck getting people to volunteer for implanting, though, and as above, it only really works if you die outside of the station. Also, repaths kheiral cuffs to be accessories, so you can attach them to uniforms. They're still functional as suit sensor extenders and GPSes (when off-station). <details><summary>Screenshots</summary> <img width="469" height="91" alt="image" src="https://github.com/user-attachments/assets/2c88b151-e5ab-415a-8c41-0f166f439315" /><br> <img width="300" height="350" alt="image" src="https://github.com/user-attachments/assets/0764983a-1160-48ab-aa6a-d1aaf08a682e" /><br> <img width="300" height="350" alt="image" src="https://github.com/user-attachments/assets/98e84368-300b-453a-89a4-d922c80628e8" /> </details> ## Why It's Good For The Game Deathrattle implants are cool. Being able to know that your coworker exploded, after a non-negligible amount of setup and wrangling your fellow spaceman to let you implant them, is probably a good thing. Introduces a cooperative avenue of "Wait, my coworker just died" instead of "Hey, they haven't yelled something on comms, did they roll antag? (No. They died.)" Kheiral cuffs being uniform attachments is because having to sacrifice glove slot for them annoyed me a lot. ## Changelog 🆑 add: Nanotrasen has begun rolling out (unconfigured) expeditionary deathrattle implant kits for their mining teams for 900 points (585 points, if manually delivered). These only alert for deaths on raw mining wasteland, and will not work in space, ruins, or on-station. balance: Kheiral cuffs can now be attached to uniforms as accessories. They retain their suit sensor extension/GPS functionality (still only when off station Z-levels, though). fix: Beacon implants now turn off (hide themselves on prisoner management consoles) after ten minutes, matching the tracking implant's functionality. qol: Made the implant pad UI a little nicer to look at, with dropdowns and demarcated sections. code: Implants now have separated "immediately useful" information and "extended lore tidbits" information as variables instead of one unchangeable get_info() block. /🆑 --------- Co-authored-by: Hatterhat <Hatterhat@users.noreply.github.com> |
||
|
BloopandGitHub
|
acaae89cf6 |
Removes some cargo culty global lists that don't need to be global lists (#94531)
## About The Pull Request Not really sure why these were there storing the lists in memory permanently, when these just get consumed anyway. People copy paste them all over it seems so I'm going to put a stop to that. ## Why It's Good For The Game Cleans up like 7 years of cargo cult. ## Changelog Not player-facing |
||
|
|
455fe545e0 |
Part 4: Storage Improvements (#90783)
## About The Pull Request - Address https://github.com/tgstation/tgstation/pull/90476#discussion_r2051701283. Makes pill bottle code cleaner - Datumized some more storage values(monkey guncase toolbox & crafter toolbox) making their init slightly faster - Moved all standard storage subtypes(bags, boxes, lockboxes etc) that is scattered across various files & folders in the codebase into their respective files under `code/game/objects/item/storage` folder. This means for e.g. if you want to see all boxes in the game you can find them in `code/game/objects/item/storage/boxes` folder & don't have to go looking for hidden subtypes in various module files or folders where they were hidden away. Makes looking for stuff & modifying these storages much saner & easier ## Changelog 🆑 code: organized storage subtypes under the same files & folders /🆑 --------- Co-authored-by: _0Steven <42909981+00-Steven@users.noreply.github.com> |
||
|
SmArtKarandGitHub
|
6b83a91956 |
Revert "Refactor for storage initialization & organization (#89543)" (#90332)
## About The Pull Request Reverts the storage initialization refactor and all subsequent related PRs. The original PR is below our standards both for code quality and testing, and is majorly flawed at its core. This has been discussed with other maintainers and headcoder(s?) over on discord. A lot of changes from the PR could be brought over later, but in its current state it should not have been merged. - Closes #90322 - Closes #90313 - Closes #90315 - Closes #90320 - Closes #90312 - Closes #90344 ## Why It's Good For The Game This PR causes a series of major issues which cannot be resolved without either completely rewriting a lot of the original PR, or bad code. Not matching our standards is grounds for not merging a PR, and the fact that a PR should not have been merged is a reason for a revert. ## Changelog 🆑 fix: Fixed a series of storage-related bugs caused by a refactor PR. /🆑 |
||
|
SyncIt21andGitHub
|
0f57a23830 |
Refactor for storage initialization & organization (#89543)
## About The Pull Request A Huge chunk of changes just comes from moving existing storage code into new files & seperating `atom_storage` code into its own subtype under the already existing `storage/subtypes` folder. With that the changes in this PR can be organized into 3 categories. **1. Refactors how `/obj/item/storage/PopulateContents()` initializes storages** - Fixes #88747 and every other storage item that has a similar variant of this problem The problem with `PopulateContents()` is that it allows you to create atoms directly inside the storage via `new(src)` thus bypassing all the access restrictions enforced by `/datum/storage/can_insert()` resulting in storages holding stuff they shouldn't be able to hold. Now how this proc works has been changed. It must now only return a list of items(each item in the list can either be a typepath or a solid atom or a mix of them in any order) that should be inserted into the storage. Each item is then passed into `can_insert()` to check if it can fit in the storage. If your list contains solid atoms they must be first moved to/Initialized in nullspace so `can_insert()` won't count it as already inserted. `can_insert()` has now also been refactored to throw stack traces but explaining exactly why the item could not fit in the storage thus giving you more debugging details to fix your stuff. A large majority of changes is refactoring `PopulateContents()` to return a list instead of simply creating the item in place so simple 1 line changes & with that we have fixed all broken storages(medical toolbox. electrical toolbox, cruisader armor boxes & many more) that hold more items they can handle **2. Organizes initialization of `atom_storage` for storage subtypes.** All subtypes of `/obj/item/storage` should(not enforced) create their own `/datum/storage/` subtype under the folder `storage/subtypes` if the default values are not sufficient. This is the 2nd change done across all existing storages Not only does this bring code cleanliness & organization (separating storage code from item code like how `/datum/wire` code is separated into its own sub folder) but it also makes storage initialization slightly faster (because you are not modifying default values after `atom_storage` is initialized but you are directly setting the default value in place). You now cannot & should not modify `atom_storage` values inside `PopulateContents()`. This will make that proc as pure as possible so less side effects. Of course this principle is not enforced and you can still modify the storage value after `Initialize()` but this should not be encouraged in the future **3. Adds support for automatic storage computations** Most people don't understand how `atom_storage` values work. The comment here clearly states that https://github.com/tgstation/tgstation/blob/55bbfef0da70d87455ca8d6fd5c95107eb8dbefb/code/game/objects/items/storage/toolbox.dm#L327-L329 Because of that the linked issue occurs not just for medical toolbox but for a lot of other items as well. Which is why if you do not know what you doing, `PopulateContents()` now comes with a new storage parameter i.e. `/datum/storage_config` This datum allows you to compute storage values that will perfectly fit with the initial contents of your storage. It allows you to do stuff like computing `max_slots`, `max_item_weight`, `max_total_weight` etc based on your storage initial contents so that all the contents can fit perfectly leaving no space for excess. ## Changelog 🆑 fix: storages are no longer initialized with items that can't be put back in after taking them out refactor: storage initialization has been refactored. Please report bugs on github /🆑 |
||
|
|
16bdcf409c |
"Security Implant" rework, prisoner management console updates (#79882)
## About The Pull Request For the vernacular purposes of the following PR body -- "Security Implant" refers to the existing subset of implants given, by security, to captured prisoners and such as a punitive, controlling measure. This includes the chemical, tracking, and maybe exile implants. This revamps the functionality of how "security" implants are displayed on huds, prisoner management console implant controls/readouts, and their instrumentality. It was also, ultimately, an attempt at nerfing the tracking implant that spiralled far out of control. Rather than only displaying chemical on the right and tracking on the left, all implants with the "security implant" flag will be trackable on SecHuds. A maximum of two can be implanted at once. This is both due to technical limitations, but also conveniently provides security a limit to consider when choosing implants. Implants now also occupy their HUD slot based on the order they were implanted in, rather than always occupying the same spot. Neat!  From two (three if you count the exile implant), there are now five security implants. _The tracker implant has been split into two of these implants._ <details> <summary>Summary of the implants, functions, changes:</summary> <br> - **Tracker (Red)** -- No longer grants teleporter beacon. Tracking radius has been increased from 20 to 35 tiles. The Prisoner Management Console will now list the area the prisoner is occupying as well. Disables after the implantee is dead for 10 minutes. - **Chemical (Blue)** -- No mechanical changes. The implant pad readout has been modified slightly. - **Exile (Green)** -- In addition to past functionality, station shuttle controls (public, mining, etc.) will be unresponsive for the implantee. Flimsy, but more effective than a stern warning not to come back from lavaland. - **Beacon (Yellow)** -- Implantee becomes a teleporter beacon. The prisoner console will report if their currently occupied area is hazardous or not, so half of the security team doesn't blindly teleport into space or lava. Disables after the implantee is dead for 10 minutes. Available from Cargo. - **Teleport Blocker (Deep Blue, not shown)** -- Prevents the implantee from being teleported. Ever wanted to keep a wizard or cultist in a cell? This is where you can start. Available from Cargo, expensive and scarce. Each of the implants has some application that would benefit security if used on a captured criminal. Their usefulness may overlap in some places, but the overall range of control these implants give security is broadened. </details> The implant control console has also been given a small facelift. Certain implants provide more useful readouts that can help officers locate, control, or capture an implantee, rewarding cooperation between officers. It has also been totally converted into TGUI by @MrMelbert. Kickass! Also, You can now remotely destroy implants, either to relieve criminals from their punishment or to make room for a different implant. Wardens should keep hold of their ID and remember to log out, since a motivated convict could use it to shed their implants!  Everything made in this PR _should_ be scaleable enough to allow for new security implant types to be implemented with relative ease. The teleport-blocker implant was a last minute attempt to prove it to myself. I had a few more ideas for implants in my head, but figured this PR was already getting big and ugly enough. That is all for another day. I truly apologize if there's anything I've missed in here. I did a lot of this over a long period of time and kind of just... sat on it for a while. If there's any confusing our unexplained changes, feel free to point them out and I'll try to give an explanation. ## Why It's Good For The Game The goal of this PR is to give a bit more depth to security's armory implants. The intent is to present a choice in what implants are given (rather than just tracker and maybe chem if you're feeling spiteful), and to make them more useful as punitive/monitoring tools. The tracker implant needed a nerf (and probably still does regardless of this PR's success). It's never used for tracking since the teleporter beacon is much more direct (+ gives a virtually free attack opportunity), and the tracking range was incredibly subpar. I'd rather not take toys away from security, but having the best option not be roundstart gear feels like a fair compromise. Warden content. Wardens have more gear to budget for and use at their own (or the HOSes) discretion. The changes to the prisoner console allow them to coordinate with officers to get good value out of the implants they've chosen for an implantee. Gives antagonists an alternate way to get de-implanted, without external help, that can only be granted at the fault of security. Wardens who dish out implants must keep an eye on the people carrying them! ## Changelog 🆑 Rhials, MrMelbert add: The Tracker implant has had its teleport beacon functionality migrated to the new (cargo accessible) Beacon implant. add: Teleport Blocker security implant, that prevents the implantee from teleporting by any means. Purchasable from cargo. add: Security implants may now be harmlessly self-destructed at the Prisoner Management Console. balance: The Tracker implant tracking radius has increased from 20 to 35 tiles. The Prisoner Management Console will track and display the area the implantee is in as well. balance: The exile implant now prevents implantees from operating shuttle controls. code: Various code improvements and removal of unused vars in the Prisoner Management Console code: The HUD slots for chem/tracking implants have been converted to display any implant with the IMPLANT_TYPE_SECURITY flag and an associated sprite. spellcheck: Modifies various implant pad readouts, removing false information and rewriting some sections. /🆑 --------- Co-authored-by: MrMelbert <kmelbert4@gmail.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |