14 Commits

Include renames

Author	SHA1	Message	Date
+3747 people	21b4095dfd	[MDB IGNORE] [IDB IGNORE] Upstream Sync - 04/17/2026 (#5453) ... Upstream 04/17/2026 fixes https://github.com/Bubberstation/Bubberstation/issues/5549 --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: tgstation-ci[bot] <179393467+tgstation-ci[bot]@users.noreply.github.com> Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: Rhials <28870487+Rhials@users.noreply.github.com> Co-authored-by: rageguy505 <54517726+rageguy505@users.noreply.github.com> Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com> Co-authored-by: Aliceee2ch <160794176+Aliceee2ch@users.noreply.github.com> Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> Co-authored-by: Tsar-Salat <62388554+Tsar-Salat@users.noreply.github.com> Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> Co-authored-by: Maxipat <108554989+Maxipat112@users.noreply.github.com> Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> Co-authored-by: deltanedas <39013340+deltanedas@users.noreply.github.com> Co-authored-by: SimplyLogan <47579821+loganuk@users.noreply.github.com> Co-authored-by: loganuk <fakeemail123@aol.com> Co-authored-by: Leland Kemble <70413276+lelandkemble@users.noreply.github.com> Co-authored-by: FalloutFalcon <86381784+FalloutFalcon@users.noreply.github.com> Co-authored-by: Roxy <75404941+TealSeer@users.noreply.github.com> Co-authored-by: Lucy <lucy@absolucy.moe> Co-authored-by: siliconOpossum <138069572+siliconOpossum@users.noreply.github.com> Co-authored-by: Isratosh <Isratosh@hotmail.com> Co-authored-by: TheRyeGuyWhoWillNowDie <70169560+TheRyeGuyWhoWillNowDie@users.noreply.github.com> Co-authored-by: Neocloudy <88008002+Neocloudy@users.noreply.github.com> Co-authored-by: Alexander V. <volas@ya.ru> Co-authored-by: ElGitificador <168473461+ElGitificador@users.noreply.github.com> Co-authored-by: Twaticus <46540570+Twaticus@users.noreply.github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> Co-authored-by: Cameron Lennox <killer65311@gmail.com> Co-authored-by: Tim <timothymtorres@gmail.com> Co-authored-by: Iamgoofball <iamgoofball@gmail.com> Co-authored-by: Layzu666 <121319428+Layzu666@users.noreply.github.com> Co-authored-by: Arturlang <24881678+Arturlang@users.noreply.github.com> Co-authored-by: _0Steven <42909981+00-Steven@users.noreply.github.com> Co-authored-by: mrmanlikesbt <99309552+mrmanlikesbt@users.noreply.github.com> Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com> Co-authored-by: John F. Kennedy <54908920+MacaroniCritter@users.noreply.github.com> Co-authored-by: Cursor <102828457+theselfish@users.noreply.github.com> Co-authored-by: Josh <josh.adam.powell@gmail.com> Co-authored-by: Josh Powell <josh.powell@softwire.com> Co-authored-by: Yobrocharlie <Charliemiller5617@gmail.com> Co-authored-by: Hardly3D <66234359+Hardly3D@users.noreply.github.com> Co-authored-by: shayoki <96078776+shayoki@users.noreply.github.com> Co-authored-by: LT3 <83487515+lessthnthree@users.noreply.github.com>	2026-05-16 00:56:00 +02:00
SmArtKarandGitHub	f58b8511f0	Refactors effect_system (#94999) ... ## About The Pull Request This PR refactors ``effect_system``s to be a bit easier to use by getting rid of ``set_up``, allowing ``attach()`` to be chained into ``start()`` and refactoring most direct system usages in our code to use helper procs. ``set_up`` was unnecessary and only existed to allow ``New``'s behavior to be fully overriden, which is not required if we split sparks/lightning/steam into a new ``/datum/effect_system/basic`` subtype which houses the effect spreading behavior. This allows us to roll all logic from ``set_up`` into ``New`` and cut down on code complexity. Chaining setup as ``system.attach(src).start()`` also helps a bit in case no helper method exists I've added ``do_chem_smoke`` and ``do_foam`` helpers, which respectively allow chemical smoke or foam to be spawned easily without having to manually create effect datums and reagent holders. Also turns out we've had some nonfunctional effect systems which either never set themselves up, or never started, so I fixed those while I was at it (mostly by moving them to aforementioned helper procs) ## Why It's Good For The Game Cleaner code, makes it significantly easier for users to work with. Also most of our effect system usage was copypasta which was passing booleans as numbers, while perfectly fine helper procs existed in our code. ## Changelog 🆑 refactor: Refactored sparks, foam, smoke, and other miscellaneous effect systems. refactor: Vapes now have consistent rigging with cigs using the new system. fix: Fixed some effects never working. /🆑	2026-02-03 22:23:09 -05:00
3 people	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>	2026-01-04 16:55:09 +00:00
Xander3359andGitHub	bbe729aef7	Converts more attackby's to interactions (#93106) ... ## About The Pull Request Converts the following: - Medical Kiosk - Implant case - Flamethrower - Chemical implant case - Pappercutter Also I've looked at some alt click procs and adjusted some of their returns	2025-10-12 22:40:42 -05:00
MrMelbertandGitHub	5261efb67f	Re-refactors batons / Refactors attack chain force modifiers (#90809) ... ## About The Pull Request Melee attack chain now has a list passed along with it, `attack_modifiers`, which you can stick force modifiers to change the resulting attack This is basically a soft implementation of damage packets until a more definitive pr, but one that only applies to item attack chain, and not unarmed attacks. This change was done to facilitate a baton refactor - batons no longer hack together their own attack chain, and are now integrated straight into the real attack chain. This refactor itself was done because batons don't send any attack signals, which has been annoying in the past (for swing combat). ## Changelog 🆑 Melbert refactor: Batons have been refactored again. Baton stuns now properly count as an attack, when before it was a nothing. Report any oddities, particularly in regards to harmbatonning vs normal batonning. refactor: The method of adjusting item damage mid-attack has been refactored - some affected items include the Nullblade and knives. Report any strange happenings with damage numbers. refactor: A few objects have been moved to the new interaction chain - records consoles, mawed crucible, alien weeds and space vines, hedges, restaurant portals, and some mobs - to name a few. fix: Spears only deal bonus damage against secure lockers, not all closet types (including crates) /🆑	2025-05-19 13:32:12 +10:00
SyncIt21andGitHub	c135b48114	Makes check_teleport_valid pure & signal clean up (#90738) ... ## About The Pull Request - Closes #90704 The following changes were implemented for this - Moved sending signals `COMSIG_MOVABLE_TELEPORTING` & `COMSIG_ATOM_INTERCEPT_TELEPORTING` from `check_teleport_valid` into `do_teleport`. These 2 signals were causing all the side effects - Removed signals `COMSIG_ATOM_INTERCEPT_TELEPORTED` & `COMSIG_MOVABLE_TELEPORTED` as the above 2 signals can do their jobs & block the teleport if needed so these signals became obsolete - Removed define `COMPONENT_BLOCK_TELEPORT` in favour of returning a positive value if teleport was successfully blocked. Having 2 signals located in 2 separate files use this same define doesn't look great. ## Changelog 🆑 code: cleans up teleportation code. `check_teleport_valid` is now a pure function with no side effects /🆑	2025-04-26 16:37:57 +02:00
GhomandGitHub	339616ae78	You can now interact with held mobs beside wearing them (feat: "minor" melee attack chain cleanup) (#90080) ... ## About The Pull Request People can now pet held mothroaches and pugs if they want to, or use items on them, hopefully without causing many issues. After all, it only took about a couple dozen lines of code to make... ...Oh, did the 527 files changed or the 850~ lines added/removed perhaps catch your eye? Made you wonder if I accidentally pushed the wrong branch? or skewed something up big time? Well, nuh uh. I just happen to be fed up with the melee attack chain still using stringized params instead of an array/list. It was frankly revolting to see how I'd have had to otherwise call `list2params` for what I'm trying to accomplish here, and make this PR another tessera to the immense stupidity of our attack chain procs calling `params2list` over and over and over instead of just using that one call instance from `ClickOn` as an argument. It's 2025, honey, wake up! I also tried to replace some of those single letter vars/args but there are just way too many of them. ## Why It's Good For The Game Improving old code. And I want to be able to pet mobroaches while holding them too. ## Changelog 🆑 qol: You can now interact with held mobs in more ways beside wearing them. /🆑	2025-04-23 20:18:26 +00:00
JacquerelandGitHub	9c8954cda5	Fix some inverted teleport validation checks (#88967) ... ## About The Pull Request A bunch of places in code were recently updated to use a helper proc for validating teleportation. Unfortunately a lot of them also got the return value inverted, and would only let you teleport to illegal locations. Most notably this effected the hand teleporter, but also several other items. Fixes #88966 what is a "dull universal force" supposed to be anyway	2025-01-09 13:50:02 -06:00
carlarctgandGitHub	d7460f97d7	Adds a new area flag, LOCAL_TELEPORT, given to virtual domains and deathmatch arenas. (#88756) ... ## About The Pull Request Adds a new area flag, LOCAL_TELEPORT. This flag allows teleports ONLY in the same area that the teleport is used. This allows for short range hijinks without enabling long range exploits, and thus it's given to DMs and domains. Changed almost all area_flags & NO_TELEPORT checks to use check_teleport() (as now areas may use local_teleport instead, and this lets them check for multiple things instead) Thus I re-added Void Phase to the heretic scribe in DM and shuffled some stuff around (realizing now i neglected to doublecheck if blade breaking tps you to station. need to check just in case) ## Why It's Good For The Game It sucks you can't use teleporting abilities in temporary areas, so this is a good way to allow this to still happen without opening the way for gamebreaking exploits. ## Changelog 🆑 code: Adds a new area flag, LOCAL_TELEPORT, given to virtual domains and deathmatch arenas. code: Re-added Void Phase to Heretic Scribes in Deathmatch's Ragnarok map. /🆑	2025-01-06 08:55:58 -05:00
san7890andGitHub	a4328ae1f9	Audits tgui_input_text() for length issues (#86741) ... Fixes #86784 ## About The Pull Request Although some of the issues found were a direct result from #86692 (c698196766), there was still 40% of length-related issues that wouldn't be covered anyways that are fixed in this PR. I.E.: * Name inputs without `MAX_NAME_LEN` * Desc inputs without `MAX_DESC_LEN` * Plaque inputs without `MAX_PLAQUE_LEN` * Some people just screwed up the arguments so it would prefill something like "40" in the `default` var because they didn't name their vars. To help me audit I added a lot of `max_length` named arguments to help people understand it better. I think it might be kinder to have a wrapper that handles adding `MAX_MESSAGE_LEN` in a lot of these cases but I think there is some reason for a coder to be cognitive about input texts? Let me know what you think. I didn't update anything admin-related from what I can recall, let me know if anything needs to be unlimited again. ## Why It's Good For The Game The change to `INFINITY` notwithstanding, there were still an abundance of issues that we needed to check up on. A lot of these are filtered on down the line but it is clear that there needs to be something to catch these issues. Maybe we could lint to make `max_length` a mandatory argument? I don't know if that's necessary at all but I think that the limit should be set by the invoker due to the wide arrangement of cases that this proc could be used in. This could all be a big nothingburger if the aforementioned PR is reverted but a big chunk of cases fixed in this PR need to be fixed regardless of that since people could put in 1024 character names for stuff like guardians (or more now with the change). Consider this "revert agnostic". ## Changelog 🆑 fix: A lot of instances where you could fill in 1024-character names (normal limit is 42) have been patched out, along with too-long plaque names, too-long descriptions, and more. /🆑	2024-09-20 22:46:41 +00:00
RhialsandGitHub	e2c4ab9900	Teleport blocker security implants prevent jaunting (#86597) ... ## About The Pull Request This extends the teleport blocker security implant's capabilities to block jaunts. All jaunt subtypes (ethereal, ashen passage, shadow walk) are blocked and stun you upon attempting to use them. This took way more trial and error than it should have. ## Why It's Good For The Game This was my initial vision when I added these. I even marketed them as being useful for keeping a wizard or heretic contained, but that turned out to be false advertising. After being served a civil claim under Section 43(a) of the Lanham Act, I have been fined an undisclosed amount of money and am being forced to rectify this. Jokes aside, this was my intent from the get-go, and I'm only just now getting around to making it so. It also just makes sense, because jaunting is basically just teleporting with extra steps. ## Changelog 🆑 Rhials balance: Teleport blocker implants now prevent implantees from jaunting. /🆑	2024-09-12 17:19:27 +02:00
MrMelbertandGitHub	ff6b41aa07	Afterattack is dead, long live Afterattack (#83818) ... ## About The Pull Request - Afterattack is a very simple proc now: All it does is this, and all it's used for is for having a convenient place to put effects an item does after a successful attack (IE, the attack was not blocked)  - An overwhelming majority of afterattack implementations have been moved to `interact_with_atom` or the new `ranged_interact_with_atom` I have manually tested many of the refactored procs but there was 200+ so it's kinda hard ## Why It's Good For The Game Afterattack is one of the worst parts of the attack chain, as it simultaneously serves as a way of doing random interactions NOT AT ALL related to attacks (despite the name) while ALSO serving as the defacto way to do a ranged interaction with an item This means careless coders (most of them) may throw stuff in afterattack without realizing how wide reaching it is, which causes bugs. By making two well defined, separate procs for handing adjacent vs ranged interactions, it becomes WAY WAY WAY more easy to develop for. If you want to do something when you click on something else and you're adjacent, use `interact_with_atom` If you want to do something when you click on something else and you're not adjacent, use 'ranged_interact_with_atom` This does result in some instances of boilerplate as shown here:  But I think it's acceptable, feel free to oppose if you don't I'm sure we can think of another solution ~~Additionally it makes it easier to implement swing combat. That's a bonus I guess~~ ## Changelog 🆑 Melbert refactor: Over 200 item interactions have been refactored to use a newer, easier-to-use system. Report any oddities with using items on other objects you may see (such as surgery, reagent containers like cups and spray bottles, or construction devices), especially using something at range (such as guns or chisels) refactor: Item-On-Modsuit interactions have changed slightly. While on combat mode, you will attempt to "use" the item on the suit instead of inserting it into the suit's storage. This means being on combat mode while the suit's panel is open will block you from inserting items entirely via click (but other methods such as hotkey, clicking on the storage boxes, and mousedrop will still work). refactor: The detective's scanner will now be inserted into storage items if clicked normally, and will scan the storage item if on combat mode /🆑	2024-06-11 21:58:09 -07:00
John WillardandGitHub	fa9a2a701a	Implant pad TGUI (#80978) ... ## About The Pull Request I was messing a little bit with TGUI stuff and ended up turning the implant pad TGUI, so why not. On top of the new UI, I replaced the messages to chat with nice and consistent balloon alerts which will hopefully make it not seem like an ancient piece of shit. Video demonstration https://github.com/tgstation/tgstation/assets/53777086/a1ebe0d4-005b-4e29-a623-2c1b352cd017 I also removed ``INTERACT_MACHINE_SET_MACHINE`` from the prisoner console, because it was accidentally left in when the console was moved to TGUI ## Why It's Good For The Game I'm still going down the list of things that need to be TGUI, and I ended up doing this cause I just felt like it while messing with some other stuff. Rest of the list is visible here: https://hackmd.io/@sClqlHM0T4yZfn-qa5KnAg/S152Tl2hh ## Changelog 🆑 refactor: Implant pads now use TGUI /🆑	2024-01-17 04:37:03 -05:00
4 people	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>	2023-12-09 17:15:19 +01:00