mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-12 08:36:00 +01:00
master
325 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Alexis
|
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> |
||
|
MrMelbert
|
e4f533111f |
Deafness is now solely tracked by trait (#95029)
## About The Pull Request Deletes `can_hear`, replaces it with trait-checking deafness. The only two non-trait sources of deafness (hardcrit and lacking ears) were refactored into using the trait. ## Why It's Good For The Game Many places inconsistently check for the deaf trait rather than use can_hear which meant behavior was not consistent. Some code would treat "do we lack ears?" as being deaf, some would not. This unifies all the behavior so being deaf means you're deaf everywhere. It also means we can now easily react to gaining and losing deafness via signal, where before we could not react to it without hooking the trait, organ remove, AND stat change. Which no one did, of course, because who would ever think to do that? ## Changelog 🆑 Melbert refactor: Refactored how deafness is tracked. Please report any weird interactions with sounds, like messages or sfx being missing. fix: Lacking ears and being in hard crit now consistently treats you as "being deaf". This affects a few minor interactions like empath, the jukebox, and sleeping. /🆑 |
||
|
Jacquerel
|
faf2000100 |
Rust doesn't apply effects to people who aren't touching it (#94733)
## About The Pull Request Heretic rusted tiles do not apply any effects to things which are jaunting or inside vents. They also don't apply any _negative_ effects to things that are flying (but they do apply positive ones, just because flight is a cool thing to have earned and it would be sad to lose your bonuses because you have wings). I also renamed the element so that it isn't named after the rust passive (in fact, the rust heretics with that passive don't use the element) and simply describes what it does, and removed a subtype in favour of just passing in some arguments. I also added a trait which bypasses the negative effects of standing in rust, in case an admin creates a non-heretic creature and gives it rust healing. They shouldn't have _both_ healing _and_ gain disgust and minor damage from starting in rust (possibly the heretical harvester was being effected by this?) Finally I adjusted the `rust_heretic_act` and `rust_turf` procs to remove a footgun I saw a developer fall into recently where they didn't realise that the generically named "rust turf" proc actually assumes a wizard did it, now if we add anything else that wants to non-magically rust a turf then it will work the way you expect. As a side effect this changes the two item sources of rust that heretics get to actually use rust resistance rather than rusting every turf, I set them to effect all inorganic turfs as a default. And finally I noticed that rust heretic ascension was passing "RUST_RESISTANCE_ABSOLUTE" as a value into its proc which reads `Should not be rustable. EVER.` in its comment, which smelled like a bug. So I changed it to just "things which should be rustable ever". ## Why It's Good For The Game It is the logical way you would expect these things to work; Heretics crawling in vents or (for instance) using space crawl should not be healed for touching rust that they aren't touching, as they are not readily accessible to other players. The idea of the rust healing is that it's a tradeoff for exposing yourself in a visible "territory", so you shouldn't be able to avoid it by being in that territory but untouchable and invisible. Similarly, players who have gained the ability to fly would not expect to get sick from flying over rusty flooring. They're out of range. ## Changelog 🆑 balance: Eldritch rusted tiles don't apply their effects to anyone who is jaunted or in vents, and don't apply negative effects to people who are flying. balance: Heretic items which apply rust (grenades and eldritch reagent) check the rust resistance level of the turf rather than always rusting it. fix: Rust Heretics ascending don't rust unrustable turfs, like space tiles. /🆑 |
||
|
FalloutFalcon
|
e7615580ac |
Better recoil visuals (#93904)
## About The Pull Request Port of https://github.com/shiptest-ss13/Shiptest/pull/3330 Partial port of https://github.com/shiptest-ss13/Shiptest/pull/1601 Makes two changes to how guns handle recoil. - Changes recoil from an erratic shaking to a kicking of your screen relative to your firing angle - Adds a small cosmetic recoil to all ballistics (with an accompanying pref option to tweak or disable it) Primary recoil still is only used as a balance lever for a very small handful of guns (and sawoff) ## Why It's Good For The Game Cosmetic recoil makes guns feel a lot more punchier. People who think its a competitive disadvantage (nerds/loosers) or people with a legitimate sickness to screen shake or similar can just turn it off. Old recoil was just reused explosion, while new recoil feels like its actually recoil |
||
|
MrMelbert
|
750ca9d2ec | Two as anything greps (and some other cleanup) (#92974) | ||
|
MrMelbert
|
4c277dc572 |
Dynamic Rework (#91290)
## About The Pull Request Implements https://hackmd.io/@tgstation/SkeUS7lSp , rewriting Dynamic from the ground-up - Dynamic configuration is now vastly streamlined, making it far far far easier to understand and edit - Threat is gone entirely; round chaos is now determined by dynamic tiers - There's 5 dynamic tiers, 0 to 4. - 0 is a pure greenshift. - Tiers are just picked via weight - "16% chance of getting a high chaos round". - Tiers have min pop ranges. "Tier 4 (high chaos) requires 25 pop to be selected". - Tier determines how much of every ruleset is picked. "Tier 4 (High Chaos) will pick 3-4 roundstart[1], 1-2 light, 1-2 heavy, and 2-3 latejoins". - The number of rulesets picked depends on how many people are in the server - this is also configurable[2]. As an example, a tier that demands "1-3" rulesets will not spawn 3 rulesets if population <= 40 and will not spawn 2 rulesets if population <= 25. - Tiers also determine time before light, heavy, and latejoin rulesets are picked, as well as the cooldown range between spawns. More chaotic tiers may send midrounds sooner or wait less time between sending them. - On the ruleset side of things, "requirements", "scaling", and "enemies" is gone. - You can configure a ruleset's min pop and weight flat, or per tier. - For example a ruleset like Obsession is weighted higher for tiers 1-2 and lower for tiers 3-4. - Rather than scaling up, roundstart rulesets can just be selected multiple times. - Rulesets also have `min_antag_cap` and `max_antag_cap`. `min_antag_cap` determines how many candidates are needed for it to run, and `max_antag_cap` determines how many candidates are selected. - Rulesets attempt to run every 2.5 minutes. [3] - Light rulesets will ALWAYS be picked before heavy rulesets. [4] - Light injection chance is no longer 100%, heavy injection chance formula has been simplified. - Chance simply scales based on number of dead players / total number off players, with a flag 50% chance if no antags exist. [5] [1] This does not guarantee you will actually GET 3-4 roundstart rulesets. If a roundstart ruleset is picked, and it ends up being unable to execute (such as "not enough candidates", that slot is effectively a wash.) This might be revisited. [2] Currently, this is a hard limit - below X pop, you WILL get a quarter or a half of the rulesets. This might be revisited to just be weighted - you are just MORE LIKELY to get a quarter or a half. [3] Little worried about accidentally frontloading everything so we'll see about this [4] This may be revisited but in most contexts it seems sensible. [5] This may also be revisited, I'm not 100% sure what the best / most simple way to tackle midround chances is. Other implementation details - The process of making rulesets has been streamlined as well. Many rulesets only amount to a definition and `assign_role`. - Dynamic.json -> Dynamic.toml - Dynamic event hijacked was ripped out entirely. - Most midround antag random events are now dynamic rulesets. Fugitives, Morphs, Slaughter Demons, etc. - The 1 weight slaughter demon event is gone. RIP in peace. - There is now a hidden midround event that simply adds +1 latejoin, +1 light, or +1 heavy ruleset. - `mind.special_role` is dead. Minds have a lazylist of special roles now but it's essentially only used for traitor panel. - Revs refactored almost entirely. Revs can now exist without a dynamic ruleset. - Cult refactored a tiny bit. - Antag datums cleaned up. - Pre round setup is less centralized on Dynamic. - Admins have a whole panel for interfacing with dynamic. It's pretty slapdash I'm sure someone could make a nicer looking one.   - Maybe some other things. ## Why It's Good For The Game See readme for more info. Will you see a massive change in how rounds play out? My hunch says rounds will spawn less rulesets on average, but it's ultimately to how it's configured ## Changelog 🆑 Melbert refactor: Dynamic rewritten entirely, report any strange rounds config: Dynamic config reworked, it's now a TOML file refactor: Refactored antag roles somewhat, report any oddities refactor: Refactored Revolution entirely, report any oddities del: Deleted most midround events that spawn antags - they use dynamic rulesets now add: Dynamic rulesets can now be false alarms add: Adds a random event that gives dynamic the ability to run another ruleset later admin: Adds a panel for messing around with dynamic admin: Adds a panel for chance for every dynamic ruleset to be selected admin: You can spawn revs without using dynamic now fix: Nuke team leaders get their fun title back /🆑 |
||
|
John Willard
|
d8a032cb56 | Ghost lighting now updates prefs (#91592) | ||
|
MrMelbert
|
7b2d129889 |
You can't offer control of a ghost to ghosts (#91250)
## About The Pull Request Blocks dead mobs (observers and new players) from `Offer Control to Ghosts` ## Why It's Good For The Game Doesn't do nothin' ## Changelog 🆑 Melbert admin: VV stops you from offering control of a ghost to ghosts /🆑 |
||
|
Kapu1178
|
a0e862d575 |
Base implementation of /datum/persistent_client (#89449)
## About The Pull Request Converts `/datum/player_details` into `/datum/persistent_client`. Persistent Clients persist across connections. The only time a mob's persistent client will change is if the ckey it's bound to logs into a different mob, or the mob is deleted (duh). Also adds PossessByPlayer() so that transfering mob control is cleaner and makes more immediate sense if you don't know byond-fu. ## Why It's Good For The Game Clients are an abstract representation of a connection that can be dropped at almost any moment so putting things that should be stable to access at any time onto an undying object is ideal. This allows for future expansions like abstracting away client.screen and managing everything cleanly. |
||
|
Rhials
|
2e7be24aad |
Honor-riffic: Adds toggleable honorific titles to certain job ID trims (#88309)
## About The Pull Request This implements a new, minor, but flavorful system to IDs -- Honorifics. Does going by your full name not suit you? Do you demand respect for the position on Space Station 13 that you've earned and want to be addressed by your title? Do you take yourself WAY too seriously? This is for you. Toggled by ctrl-clicking your ID, honorifics append a title to your name depending on your position. Certain titles (Captain, Officer, Doctor, etc.) will only append to the start (replacing or including the first/last name), while others (PhD., Esq.) can only be appended at the end.  Each job TRIM has a set honorific and positions it can be assigned to. A doctor can be "Doctor Peterson" or "Doctor Peterson Bungle" or "Doctor Bungle". A Lawyer can only choose to be "Peterson Bungle, Esq.". This will only occur when the speaker's voice is the same identity as the one written on the ID's registered name. This should not interfere with Unknown voice obfuscation, stolen ID shenanigans, or anything gameplay-oriented. Hopefully. This feature is also mononym friendly!  This also makes `first_name()` and `last_name()` global procs, and adds one to check if a passed string has spaces/dashes/whitespace/whatever. All of this is compatible with ID name changes, but the voice name must align with the card name to display the honorific. If you are "Peter Stinkypants" with your honorific set to display "Doctor Stinkypants", and your ID's registered name is changed to "Peter Stinker", you show up as "Peter Stinkypants (as Peter Stinker)" with no honorific provided. If you become "Peter Stinker" and have a "Peter Stinker" ID, you will show up as "Doctor Stinker" once again. That all make sense? Great. <details> <summary>So about the ID name stuff...</summary> <br> So, when you activate an honorific on your ID, it DOES change the actual object's name. Not the registered name, but the ID's name will go from "Peter Dawson's ID card" to "Captain Dawson's ID card" when an honorific is applied. This, as far as I've tested, does not mess with anything important, but I can totally see it doing so in a way that makes ctrl-Fing through logs harder than it needs to be. This could probably be changed without too much effort so if the issue does arise I can fix it. If not I am totally fine with reverting this PR until I can make it work (if I can at all). <br> Admittedly this doesn't have much testing with holopads/radios, but I'm confident the message composure is handled well enough to only display the right names under the right circumstances. If this fucks up logging or naming in any way tell me ASAP because I have a sinking feeling it will in a way more catastrophic than I could ever predict. This PR has been tested thoroughly but I have my limits. </details> |
||
|
John Willard
|
2e4d70afe5 |
Updates href uses for 516 (#88699)
## About The Pull Request Was just scrolling through the Paradise github since they seem to have more work done for 516 to see if there's anything I can port over, found this and thought why not. Ports parts of https://github.com/ParadiseSS13/Paradise/pull/25105 Specifically, updaing all hrefs to use the internal ``byond://``, and adding it to grep. ## Why It's Good For The Game More work towards 516. ## Changelog Nothing player-facing. |
||
|
grungussuss
|
61ca36dc71 |
More accessibility options and pref menu (#87549)
## About The Pull Request - added accessibility tab in prefs menu - put darkened flashes option into this menu - added `darken screen shake` pref, for motion sick people, darkens your screen when experiencing screen shake. <details> OUTDATED  </details> https://github.com/user-attachments/assets/e3fd43ad-a65c-47dc-add2-6c93048e8b61 ## Why It's Good For The Game makes it easier for people with disabilities to play the game. ## Changelog 🆑 grungussuss qol: you can now mitigate motion sickness from screen shake by enabling "darken screen shake" in preferences /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
|
tonty
|
3f0b4abb8d |
Replaces world.icon_size (and some magic numbers) with defines (#86819)
## About The Pull Request All usages of world.icon_size in code have been replaced with new `ICONSIZE_X`, `ICONSIZE_Y` and `ICONSIZE_ALL` defines depending on context Replaces some "32" magic numbers with the defines A few bits of code have been modified to split up x/y math as well ## Why It's Good For The Game Magic number bad, code more readable, code more flexible and I'm told there's an access cost to doing world.icon_size so minor performance gains ## Changelog 🆑 tonty code: made some code relating to the world's icon size more readable /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
MrMelbert
|
48bbd6fddf |
Reworks examine (a little) (#86506)
## About The Pull Request Basically, reworks how examining things looks to the user. #86497 is required even though this pretty much replaces the entire PR. Examining random objects and simplemobs:   Examining a person:   Examining an ID card a person is wearing (by clicking the hyperlink adorning the ID card when examining them): (Note, you can only pull up this if you are within 3 tiles of the person)  ## Why It's Good For The Game Examine is very old and very inconsistent between atoms and mobs. So I thought I could spruce it up a bit while bringing some consistency along. This should also help with losing certain details in massive walls of examine text - stuff like names will stick out more. ## Changelog 🆑 Melbert qol: The way examine looks has been updated. qol: A person's ID card no longer appears with a big icon on examine. You can now click on their ID card (in the chat box) to get a bigger picture of it, as well as information about them. refactor: Much of examine backend code has been refactored, report any odd looking text. /🆑 |
||
|
John Willard
|
1880003270 |
Reworks silicon/ai access checking & fixes some ui_act's (#84964)
## About The Pull Request Currently to check for Silicon access, we do: ``if is silicon or is admin ghost or has unlimited silicon privileges or has machine remote in hand`` What has unlimited silicon privileges? Bots, Drones, and admin ghosts. To check for AI access, it just checks for AI instead of silicon, and doesnt check for unlimited silicon privileges. This was kinda silly, so I thought I should make this a little easier to understand. Now all silicon/ai traits come from ``AI_ACCESS_TRAIT`` or ``SILICON_ACCESS_TRAIT``. I made a single exception to keep Admin ghost, since now instead of being a var on the client, we moved it to using the same trait but giving it to the client instead, but since we have to keep parity with previous functionality (admins can spawn in and not have this on, it only works while as a ghost), I kept previous checks as well. No more type checks, removes a silly var on the mob level and another on the client. Now while I was doing this, I found a lot of tgui's ``ui_act`` still uses ``usr`` and the wrong args, so I fixed those wherever I saw them, and used a mass replace for the args. Other changes: - machinery's ``ui_act`` from https://github.com/tgstation/tgstation/pull/81250 had ``isAI`` replaced with ``HAS_AI_ACCESS``, this has been reverted. Machine wands and admin ghosts no longer get kicked off things not on cameras. This was my fault, I overlooked this when adding Human AI. - Human AI's wand gives AI control as long as it's in your hand, you can swap to your offhand. I hope this doesn't end up going horribly, otherwise I'll revert this part. It should let human AIs not have their UI closed on them when swapping to eat food or use their door wand or whatnot. - Bots previously had special checks to scan reagents and be unobservant, I replaced this with giving them the trait. I also fixed an instance of unobservant not being used, so now statues don't affect the basic creature, whatever that is. ## Why It's Good For The Game This is an easier to understand way of handling silicon access and makes these mobs more consistent between eachother. Other than what I've mentioned above, this should have no impact on gameplay itself. ## Changelog 🆑 fix: Statues don't count as eyes to creatures. fix: Human AIs and Admin ghosts no longer get kicked off of machines that aren't on cameranets. /🆑 |
||
|
Lucy Grindler
|
6351073f56 |
Pegging Update (#83991)
## About The Pull Request We be addin' peg legs an' peg arms, makin' 'em craftable fer all ye scurvy dogs. Ye can attach 'em yerselves, no need fer a surgeon's touch, usin' the mighty ligament hook code. There be tons o' balance tweaks an' special properties fer these limbs. Yarrrrr! ## Why It's Good For The Game Arrr, this be givin' ye a ghetto alternative to headin' to medbay when yer limbs be blown off. Plus, the potential fer pirate RP be fantastic! Who doesn’t want peg limbs? If ye think otherwise, ye be lyin’ ,and ye'll be walkin’ the plank! Yarrrrr! ## Changelog 🆑 Hacks-The-Doors (coding) & Septicchlorine (spriting) add: craftable peg limbs (2 planks) which are attachable without surgery bal: peg limbs take 1.5x burn and 1.3x brute, and do reduced damage bal: peg limbs have chunky fingers (like insuls, but per limb) /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: septic <105231896+septoBismol@users.noreply.github.com> Co-authored-by: Jacquerel <hnevard@gmail.com> |
||
|
Joshua Kidder
|
5e9f1f6582 |
Cuffed people can sign (to a limited degree), signing tone emotes improvement (#83501)
## About The Pull Request Currently, if you handcuff someone and they only have sign language available to speak in (mute, no tongue, nearby people are deaf, you have bronchitis(?)), they are rendered totally unable to communicate with anything but emotes. This is stifling to trying to roleplay with nearby people who want to keep you cuffed for whatever reason (security, antagonists, weirdos who keep hugging you, etc). So instead, I've made it so that if you use sign language while handcuffed, you are still able to sign, but to a much more limited degree (3 - 5 words per message). If you're put in a straightjacket, you're still totally unable to use sign language. Additionally, I spruced up the messages that sign language uses to signify tone (?, !) and added one for EXCLAIMED QUESTIONS?! I also made the emotes work as emotes, rather than the small (easily missable) messages in the chat box. These emotes will not fire if you sign with tone while cuffed, to avoid you becoming a spam machine. ## Why It's Good For The Game It lets cuffed sign language users communicate, which is usually a pretty good thing when it comes to improving a scene for both them and the people they're playing with. It improves the descriptiveness of the inquisitive and exclamatory tone messaging for sign language users, and also adds one for a combination of the two tones. ## Changelog 🆑 qol: Sign language users can now sign in cuffs, but to a very limited degree. They also have more descriptive emotes for questions, exclamations, and a combination of the two. /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
13spacemen
|
357799c8a5 |
Removes Orbit Polling Component, SSpolling improvement (#81748)
When I made SSpolling, jlsnow gave me his blessing to delete the orbit polling component [where you orbit something for 20 seconds before it chooses a ghost from the orbiters] It's only used in a few places like soulstones replacing jobbanned/inactive players, etc. Also upgraded SSpolling; you can now place a little icon on the sides in the chat message, chat message looks a lot nicer, the alert pic and the jump target don't have to be the same anymore, and I made it be able to pre-pick candidates since 90% of the use cases would just want 1 candidate Also prints to chat who the chosen one was Also made slime intelligence potions ask the user for a reason, which will be displayed in the alert poll |
||
|
Pinta
|
275a4785ac |
TRAIT_DEAF now works on non-carbon mobs (#81624)
## About The Pull Request This PR makes it so that the `can_hear` proc will return `FALSE` if the proc is called on a non-carbon that has the deaf trait. ## Why It's Good For The Game This makes it so that non-carbon mobs can have the TRAIT_DEAF added to them and it will now work. There isn't anything that would currently utilize this on here. But, I do have a project downstream where TRAIT_DEAF is added to a non-carbon mob. ## Changelog 🆑 code: TRAIT_DEAF now works on non-carbon mobs /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
|
13spacemen
|
908d6f1a2b |
Better Ghost Selection (#80283)
## About The Pull Request Revived my old PR https://github.com/tgstation/tgstation/pull/68901 Replaces the annoying tgui alert popup "Do you want to be X? | Yes | No | Never for this round" that is hard to read and steals window focus, with a nice clean alert in the top right that counts down. If it's the same event/mob they stack with 2x, 3x, etc. It also shows how many candidates/ghosts are signed up. The poll alerts have screentips too, they countdown and show if you're signed up, how many people are signed up, if you chose "never for this round" (which is cancelable) ## Why It's Good For The Game  Way easier to see what role is available, you get a nice pic of the role and get it's name in big text, you can cancel "never for this round", and you can cancel signing up for a role before the timer is up ## Changelog 🆑 refactor: Ghost roles now offer ghosts a clickable poll button. Ghosts can select a role, deselect it, alt-click it for "Never For This Round", can cancel "Never", can see the countdown, and can see how many other people are signed up for the role poll. /🆑 |
||
|
Jeremiah
|
bbe440b3d6 |
More standardization for ghost notifications (READY) (#79596)
## About The Pull Request I'm still not satisfied with how ghost notifications work. This gives every notification with a source (99% of all notifications, in other words) a link to jump/orbit. Currently, notifications with "play" interactions would only get the interact link, so jumping to the source was pretty annoying. It removes posting the entire message in the alert tooltip, as some got pretty lengthy and it didn't seem to fit. To replace this, they will always use headers After:    NOTIFY_JUMP and NOTIFY_ORBIT have been merged, since the only difference seems to be whether it's a turf. The result shaves off some redundant lines of code, since most-every usage of notify_ghosts uses NOTIFY_ORBIT. ## Why It's Good For The Game More standardization for the ghost notification system. Adds a few alert headers that never had them. All in all, makes it easier for creators to throw alerts at ghosts ## Changelog 🆑 qol: Nearly every ghost alert should now feature a "VIEW" button, even those with click interaction. del: Ghost alerts no longer show the entire message in the tooltip, instead have been replaced with titles. /🆑 |
||
|
LemonInTheDark
|
3223d2a3fb |
Lemon fixes ci (#79384)
## About The Pull Request Sets up moveloops to better catch issues with duplicated loops Letting people modify the timer var AND have it track what bucket we're in was a bad idea. So instead let's store the queued time separate. Also makes allowed_to_move return true/false instead of flags This fixed? the null loop issue locally, I honestly have no damn idea why. I'm gonna be working on the rest of ci here, left trackers so if it pops up between now and merge I'll know what the issue is. --------- Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com> Co-authored-by: Emmett Gaines <ninjanomnom@gmail.com> |
||
|
Jeremiah
|
e2529818aa |
Reverts reverted toast icons (#79538)
## About The Pull Request During the notify ghosts refactor I was unsure why we were creating a custom overlay for each ghost alert when new_master did the same. Turns out - it resets icons, which is useful here. This also caused #79415. The original notify ghosts was performing this transformation operation O(n), which I've made O(1) ## Why It's Good For The Game Fixes #79415  ## Changelog 🆑 fix: The screen alert should no longer break ghost UI when it's huge /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
Rhials
|
3c7005a37c |
Converts some notify_ghosts args to bitflags, multilines all notify_ghosts calls (#79320)
## About The Pull Request This helps clean up my favorite helper proc in the whole codebase, `notify_ghosts()`. The notify_suiciders, ignore_mapload, and flashwindow args are GONE. They have been replaced with the notify_flags bitflag argument. This was intended to make deadchat announcements a bitflag argument too, but those got reverted right before I originally wanted to submit this PR. The on-screen popup now shows the notification body when you hover it with your mouse again. The format is now `[notify_ghosts message] -- [click action (orbit/jump/play)]` Every single `notify_ghosts()` call has been changed to multiline format and has been given trailing commas. Pretty! ## Why It's Good For The Game Cleans up a proc that is very popular and going through a lot of changes at the time. Allows for further flexibility when this proc inevitably gets tweaked or improved. 12 -> 10 args is an improvement, and it doesn't impact the helper's flexibility at all. ## Changelog 🆑 Rhials code: The notify_ghosts proc has been cleaned up. Please report any abnormal changes in deadchat notification behavior. qol: The on-screen deadchat popups now contain the notification blurb when hovered with your mouse again. /🆑 |
||
|
san7890
|
e03822fe1d |
Standardizes Adding Datum Actions into a proc/define (Bonus AI Support) (Bonus Useless Code Cleanup) (#79389)
## About The Pull Request The way we add multiple actions has been very unstandardized, with several implementations of this code doing certain things wrongly (i.e. not nullchecking `ai_controller`), so let's do something in the vein of #74037 and just make one nice big ol' proc that catches a lot of these cases. There are still a few things that simply can't be done here, but this gets the most generic "give my mob some actions and also maybe tell the AI about it" stuff done. This is only useful in cases where we don't ever need to reference the ability ever again when it's added. In an ideal world we would never need to reference the ability again and it would all be self-contained, but this is not an ideal world. However, a lot of the latticework has been built around certain implementations of this behavior making refactoring it just a bit easier. I also did a lot of auditing on `Destroy()` stuff, because `/datum/action`s listen to signals when their parent is `qdel`ing, so we don't need to neither hold nor clear references on our mob's `Destroy()`. This was all cleaned up now because even if we couldn't use `grant_multiple_actions()` (the new proc I add in this PR), it's just not useful at all and will further hinder efforts to implement this new proc. Also also, I noticed in some places (such as megafauna) that we were initializing a lot of datum actions _in nullspace_. We didn't pass the `src` argument to `New()`. I quickly fixed that, as well as got rid of the useless types we had going on. Also also also, I added a define macro to handle some of the cases that melbert was speaking about in his review down below. All you need to do is invoke the define on the typepath, and you should be good to go from there. There's probably a better way to do it, lmk though. we do the whole `do while` thing in order to prevent code leakages. ## Why It's Good For The Game * Very easy to change the implementation. In case we need to do something different in how we add actions or anything like that, we can simply just edit instances where this proc is located. * Standardizes addition behavior. There's a lot of cases like the aforementioned not-null-checking `ai_controller` that we really need to look out for, so having it all in one accessible proc ensures standard behavior. * Reduces copy-pasta. A lot of mobs had their own individual implementation of this, so let's just clean up all those lines of code. ## Changelog 🆑 refactor: The way mobs get specialized actions (like revenants shocking lights or regal rats summoning rats to their side when you slap them) have been modified, please report any bugs. /🆑 This doesn't touch the following case FTR: * Instances where we need to do work on the `/datum/action` after we `Grant()` it, like if we were to edit some variable on the action or if we need to call procs on said action. I don't like how the current code is so reliant on storing a variable to it, but that's a windmill to attack another time. |
||
|
Watermelon914
|
9dcef290ec |
Reworks the styling of the announcements and expands major announcements to also be colourable. (#79236)
## About The Pull Request The styling of the announcements has been reworked and major announcements can now be coloured too. Syndicate and hostile announcements have been given a red/orange. Wizard federation now has a purple colour. Admins can set what colour they want their announcements to be and they can also set the announcement subheader now. The colour scheme for darkmode has been changed slightly and the colour scheme for lightmode has been completely revamped. Main text body of the announcements are no longer striped to allow for easier reading. Rolled back the changes to deadchat notifications, they're now back to being normal text. Shuttle-related announcements now have an orange background <details> <summary>Light mode pictures</summary>     </details> <details> <summary>Dark mode pictures</summary>     </details> ## Why It's Good For The Game The colours for light mode were hard to read due to bad colour combinations, which caused the foreground and background to have too low contrast. Additionally, I felt like the styling was less immersive overall and that there didn't need to be so much noise over the main text body. ## Changelog 🆑 add: Reworked the colour schemes for the minor and major announcements as well as their layout del: Rolled back changes to deadchat notifications admin: Admins can now select the colour of their announcements as well as the subheader when creating a command report. /🆑 --------- Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com> |
||
|
Jacquerel
|
0d5f9907a2 |
Shapechange health transfer tweaks (#79009)
## About The Pull Request Fixes #78721 This PR does a handful of things behind the scenes to increase the consistency of shapechange health tracking. First of all we adjust the order of operations taken when you restore the original body. The implementation as-was would remove the status effect midway through and null a bunch of variables we tried to continue using. This would result in several runtimes and code failing to run, with the upshot that untransforming upon death would leave the caster completely alive, with the corpse of its transformed shape at its feet. Oops. Additionally while testing this I realised that transferring the damagew as also kind of fucked. We wouldn't bother to do it at _all_ if you died, which is a shame, so I made it simply heal you instead of reviving you so we can always do it. Then as noted in the linked issue, we were applying all transferred damage to a single limb, which could exceed the health of the limb and remove damage. Now we spread it around the body. Finally, applying damage to a human using the "force" flag would often actually apply less damage to their _health_ than expected. This is because arms and legs contribute only 75% of their damage taken to a mob's overall health. Now instead of reading `health` we read `total damage` which ignores the limb damage modifier. The end result of this is that if you transform into a corgi, take 50% of your health, and transform back then you will have 50% of your health as a human. Previously the result would be that you'd have ~63%, then transforming into a corgi would leave you with ~63% of a corgi's health, then transforming back into a human would leave you at about 71%... and so on and so forth. Now it doesn't do that. ## Changelog 🆑 fix: Dying when using (most) shapeshift spells will now kill you rather than having you pop out of the corpse of your previous form. fix: Damage will now be accurately carried between forms rather than being slightly reduced upon each transformation. /🆑 |
||
|
Jeremiah
|
153e06dc04 |
Partially reverts ghost announcements (#79221)
## About The Pull Request #79139 turned out to be quite annoying, it wasn't taken into account that these alerts can stack (ie: spiders). Of course, I poked around the code and found some inconsistencies in the process. For instance, there were usages of Topic for custom action behavior which could've been consolidated. There were other instances where jump (the default action) doesn't give a link at all, which I think it should anyway, since the screen toast gives you this. I've standardized it more, meaning you can use "NOTIFY_PLAY" without writing a custom link and topic handler (for instance, MMIs) ## Why It's Good For The Game Fixes #79198 Fixes #79195 ## Changelog 🆑 fix: Ghost alerts have been tuned down a bit. /🆑 |
||
|
Jeremiah
|
3e435cf7a9 |
Better looking ghost notifications (#79139)
## About The Pull Request The alerts have been given some style  Also the screen tip should be quite obvious  Cleaned up some code around the proc itself - really needed some TLC. That, and added an arg to minor announcements to override colors. ## Why It's Good For The Game Better styling for alerts ## Changelog 🆑 add: Just in time for Halloween- ghost notifications have been upgraded to their own announcements. Boo! /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
Bloop
|
68b798efa0 | A thorough audit of damage procs and specifically their use in on_mob_life() (with unit tests!) (#78657) | ||
|
Jacquerel
|
f861532d24 | Basic Legion & Hivelord (#78624) | ||
|
carlarctg
|
d86550773b |
Valentines and ERTs will no longer get mood boosts from traitor moodener items (#78597)
## About The Pull Request Valentines and ERTs will no longer get mood boosts from traitor moodener items Closes #73432 ## Why It's Good For The Game bugge ## Changelog 🆑 fix: Valentines and ERTs will no longer get mood boosts from traitor moodener items /🆑 |
||
|
Fikou
|
9b690fd0f8 |
ghost notifs now set the pixel x/y properly with scaling (#77239)
## About The Pull Request ghost notifs set pixel x y to 0 (so wallmounts for example are centered) and then large stuff like space dragons or singularities is properly brought down by calculations before  after  ## Changelog 🆑 fix: ghost notification icons are now centered properly /🆑 |
||
|
ChungusGamer666
|
6da96bef84 |
SPECIES NUKING 2023: Mein leber! Allows livers to handle reagents in special ways, instead of the species datum doing it (#76184)
## About The Pull Request Refactors livers so special chemical handling can be done by them, instead of the species datum. Plasmamen, skeletons and golems all use the liver for all their species specific chem handling now. ## Why It's Good For The Game SPECIES DATUM I HATE YOU! Also, being able to handle reagents like any species if you have their liver is REALLY FREAKING COOL and allows for emergent gameplay by mixing various organs from various sources. ## Changelog 🆑 refactor: Mutant livers can now handle chemicals in special ways. Currently, only plasmaman, skeleton and golem livers do it. Every other species is the same. /🆑 --------- Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> |
||
|
Zephyr
|
fbec9c14e9 |
JSON Logging Take Two (#73604)
## About The Pull Request Converts all logging, excluding perf and investigate, to json. I focused on making the system as easy to use and as easy to add new categories as possible. Due to issues related to logging to world at global creation logger is now a byond real, which is created directly before Master Log categories support versioning, secret flagging, and sub-category filtering. Although all of this is entirely optional for coders. If you ever want to add a new category and use it, all you need to do is make the barebones category datum and the define. I've kept existing procs such as log_game, and simply turned them into a wrapper for Logger.Log(xxx, ...) ## Why It's Good For The Game Makes processing and filtering logs much easier in the future, while only minimally downgrading log crawling experience. I am also working on a log viewer frontend for admin usage however that will take a little bit longer to finish up. Also makes special logging and data tracking much easier thanks to a data list processing implementation and handling ## Changelog 🆑 server: All logs are now formatted in json, excluding perf and investigations /🆑 --------- Signed-off-by: GitHub <noreply@github.com> Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com> Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com> Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com> |
||
|
oranges
|
4c48966ff8 |
Renames delta time to be a more obvious name (#74654)
This tracks the seconds per tick of a subsystem, however note that it is not completely accurate, as subsystems can be delayed, however it's useful to have this number as a multiplier or ratio, so that if in future someone changes the subsystem wait time code correctly adjusts how fast it applies effects regexes used git grep --files-with-matches --name-only 'DT_PROB' | xargs -l sed -i 's/DT_PROB/SPT_PROB/g' git grep --files-with-matches --name-only 'delta_time' | xargs -l sed -i 's/delta_time/seconds_per_tick/g' |
||
|
san7890
|
a6f49ed542 |
Refactors Suiciding Variable Into Trait (#74150)
## About The Pull Request Firstly, this var was on `/mob`, even though only `/mob/living` and `/mob/dead` could have ever used it, so who knows how much needless memory it was consuming on stuff such as `oranges_ear` that would never ever ever use something like this. Edit: okay instead of memory it just polluted variable edit windows for all /mob when it didn't need to. I like having a slim VV window Secondly, it's a technical improvement over the previous system as we are able to "track" where a suicide originates from, and how we can track that from mob-to-mob-to-mob. Previously, the boolean `suiciding` would only inform us if they had ever been connected to a mob that had ever committed suicide, but now we are able to precisely determine which mob gave them the trait that they must now apparently bear until the round restarts. ## Why It's Good For The Game Less memory usage, more indepth ability to track suicides in case you really need that dexterity. Currently no implemented code could benefit from using it, but it would be pretty neat if someone could figure out a way to have someone be guilt-tripped whenever they look into a mirror and seeing the reflection of their past life? This PR won't actually help you code that and it'll probably require a bit more work, but it's a possibility of some cool interactions you can do when you have this information available to you.  ## Changelog 🆑 refactor: Some aspects of how we track suicides from your living mob to your observer have changed- please do let us know if anything has broken via a GitHub Issue Report. /🆑 There's probably some technical improvements that can be made in some parts of the code I reworked to accommodate this change, do let me know if you spot any easy ones (or fuckups). a lot of excess comes from the fact that any step in the TRAIT framework trusts that you are passing in a valid datum (or subtype) so that's a thing |
||
|
LemonInTheDark
|
ab307032ed |
Nightvision Rework (In the name of color) (#73094)
## About The Pull Request Relies on #72886 for some render relay expansion I use for light_mask stuff. Hello bestie! Night vision pissed me off, so I've come to burn this place to the ground. Two sections to discuss here. First we'll talk about see_in_dark and why I hate it, second we'll discuss the lighting plane and how we brighten it, plus introducing color to the party. ### `see_in_dark` and why it kinda sucks https://www.byond.com/docs/ref/#/mob/var/see_in_dark See in dark lets us control how far away from us a turf can be before we hide it/its contents if it's dark (not got luminosity set) We currently set it semi inconsistently to provide nightvision to mobs. The trouble is stuff that produces light != stuff that sets luminosity. The worst case of this can be seen by walking out of escape on icebox, where you'll see this  Snow draws above the lighting plane, so the snow will intermittently draw, depending on see_in_dark and the luminosity from tracking lights. This would in theory be solvable by modifying the area, but the same problem applies across many things in the codebase. As things currently stand, to be emissive you NEED to have a light on your tile. People are bad at this, and honestly it's a bit much to expect of them. An emissive overlay on a canister shouldn't need an element or something and a list on turfs to manage it. This gets worse when you factor in the patterns I'm using to avoid drawing lights above nothing, which leads to lights that should show, but are misoffset because their parent pixel offsets. It's silly. We do it so we can have things like mesons without just handing out night vision, but even there the effect of just hiding objects and mobs looks baddddddd when moving. It's always bothered me. I'll complain about mesons more later, but really just like, they're too bright as it is. I'm proposing here that rather then manually hiding stuff based off distance from the player, we can instead show/hide using just the lighting plane. This means things like mesons are gonna get dimmer, but that's fine because they suck. It does have some side effects, things like view() on mobs won't hide stuff in darkness, but that's fine because none actually thinks about view like that, I think. Oh and I added a case to prevent examining stuff that's in darkness, and not right next to you when you don't have enough nightvision, to match the old behavior `see_in_dark` gave us. Now I'd like to go on a mild tangent about color, please bare with me ### Color and why `lighting_alpha` REALLY sucks You ever walk around with mesons on when there's a fire going, or an ethereal or firelocks down. You notice how there isn't really much color to our lights? Doesn't that suck? It's because the way we go about brighting lighting is by making everything on the lighting plane transparent. This is fine for brightening things, but it ends up looking kinda crummy in the end and leads to really washed out colors that should be bright. Playing engineer or miner gets fucking depressing. The central idea of this pr, that everything else falls out of, is instead of making the plane more transparent, we can use color matrixes to make things AT LEAST x bright. https://www.byond.com/docs/ref/#/{notes}/color-matrix Brief recap for color matrixes, fully expanded they're a set of 20 different values in a list Units generally scale 0-1 as multipliers, though since it's multiplication in order to make an rgb(1,1,1) pixel fullbright you would need to use 255s. A "unit matrix" for color looks like this: ``` list(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 ) ``` The first four rows are how much each r, g, b and a impact r, g, b and well a. So a first row of `(1, 0, 0, 0)` means 1 unit of r results in 1 unit of r. and 0 units of green, blue and alpha, and so on. A first row of `(0, 1, 0, 0)` would make 1 red component into 1 green component, and leave red, blue and alpha alone, shifting any red of whatever it's applied to a green. Using these we can essentially color transform our world. It's a fun tool. But there's more. That last row there doesn't take a variable input like the others. Instead, it ADDS some fraction of 255 to red, green, blue and alpha. So a fifth row of `(1, 0, 0, 0)` would make every pixel as red as it could possibly be. This is what we're going to exploit here. You see all these values accept negative multipliers, so we can lower colors down instead of raising them up! The key idea is using color matrix filters https://www.byond.com/docs/ref/#/{notes}/filters/color to chain these operations together. Pulling alllll the way back, we want to brighten darkness without affecting brighter colors. Lower rgb values are darker, higher ones are brighter. This relationship isn't really linear because of suffering reasons, but it's good enough for this. Let's try chaining some matrixes on the lighting plane, which is bright where fullbright, and dark where dark. Take a list like this ``` list(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, -0.2, -0.2, -0.2, 0 ) ``` That would darken the lighting a bit, but negative values will get rounded to 0 A subsequent raising by the same amount ``` list(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0.2, 0.2, 0.2, 0 ) ``` Will essentially threshold our brightness at that value. This ensures we aren't washing out colors when we make things brighter, while leaving higher values unaffected since they basically just had a constant subtracted and then readded. ### But wait, there's more You may have noticed, we gain access to individual color components here. This means not only can we darken and lighten by thresholds, we can COLOR those thresholds. ``` list(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0.1, 0.2, 0.1, 0 ) ``` Something like the above, if applied with its inverse, would tint the darkness green. The delta between the different scalars will determine how vivid the color is, and the actual value will impact the brightness. Something that's always bothered me about nightvision is it's just greyscale for the most part, there isn't any color to it. There was an old idea of coloring the game plane to match their lenses, but if you've ever played with the colorblind quirk you know that gets headachey really fast. So instead of that, lets color just the darkness that these glasses produce. It provides some reminder that you're wearing them, instead of just being something you forget about while playing, and provides a reason to use flashlights and such since they can give you a clearer, less tinted view of things while retaining the ability to look around things. I've so far applied this pattern to JUST headwear for humans (also those mining wisps) I'm planning on furthering it to mobs that use nightvision, but I wanted to get this up cause I don't wanna pr it the day before the freeze. Mesons are green, sec night vision is red, thermals orange, etc. I think the effect this gives is really really nice. I've tuned most things to work for the station, though mesons works for lavaland for obvious reasons. I've tuned things significantly darker then we have them set currently, since I really hate flat lighting and this system suffers when interacting with it. My goal with these is to give you a rough idea of what's around you, without a good eye for detail. That's the difference between say, mesons, and night vision. One helps you see outlines, the other gives you detail and prevents missing someone in the darkness. It's hard to balance this precisely because of different colored backgrounds (looking at you icebox) More can be done on this front in future but I'm quite happy with things as of now ### **EDIT** I have since expanded to all uses of nightvision, coloring most all of them. Along the way I turned some toggleable nightvision into just one level. Fullbright sucks, and I'd rather just have one "good" value. I've kept it for a few cases, mostly eyes you rip out of mobs. Impacted mobs are nightmares, aliens, zombies, revenants, states and sort of stands. I've done a pass on all mobs and items that impact nightvision and added what I thought was the right level of color to them. This includes stuff like blobs and shuttle control consoles As with glasses much of this was around reducing vision, though I kept it stronger here, since many of these mobs rely on it for engaging with the game <details> <summary> Technical Changes </summary> #### Adds filter proc (the ones that act like templates) support to filter transitions. Found this when testing this pr, seemed silly. #### Makes our emissive mask mask all light instead This avoids dumbass overlay lighting lighting up wallmounts. We switch modes if some turfflags are set, to accomplish the same thing with more overhead, and support showing things through the darkness. Also fixes a bug where you'd only get one fullscreen object per mob, so opening and closing a submap would take it away Also also fixes the lighting backdrop not actually spanning the screen. It doesn't actually do anything anymore because of the fullscreen light we have, but just in case that's unsued. Needs cleanup in future. #### Moves openspace to its own plane that doesn't draw, maxing its color with a sprite This is to support the above We relay this plane to lighting mask so openspace can like, have lighting #### Changes our definition of nightvision to the light cutoff of night vision goggles and such Side affect of removing see_in_dark. This logic is a bit weak atm, needs some work. #### Removes the nightvision spell It's a dupe of the nightvision action button, and newly redundant since I've removed all uses of it #### Cleans up existing plane master critical defines, ensures trasnparent won't render These sucked Also transparent stuff should never render, if it does you'll get white blobs which suck </details> ## Why It's Good For The Game Videos! (Github doesn't like using a summary here I'm sorry) <details> Demonstration of ghost lighting, and color https://user-images.githubusercontent.com/58055496/215693983-99e00f9e-7214-4cf4-a76a-6e669a8a1103.mp4 Engi-glass mesons and walking in maint (Potentially overtuned, yellow is hard) https://user-images.githubusercontent.com/58055496/215695978-26e7dc45-28aa-4285-ae95-62ea3d79860f.mp4 Diagnostic nightvision goggles and see_in_dark not hiding emissives https://user-images.githubusercontent.com/58055496/215692233-115b4094-1099-4393-9e94-db2088d834f3.mp4 Sec nightvision (I just think it looks neat) https://user-images.githubusercontent.com/58055496/215692269-bc08335e-0223-49c3-9faf-d2d7b22fe2d2.mp4 Medical nightvision goggles and other colors https://user-images.githubusercontent.com/58055496/215692286-0ba3de6a-b1d5-4aed-a6eb-c32794ea45da.mp4 Miner mesons and mobs hiding in lavaland (This is basically the darkest possible environment) https://user-images.githubusercontent.com/58055496/215696327-26958b69-0e1c-4412-9298-4e9e68b3df68.mp4 Thermal goggles and coloring displayed mobs https://user-images.githubusercontent.com/58055496/215692710-d2b101f3-7922-498c-918c-9b528d181430.mp4 </details> I think it's pretty, and see_in_dark sucks butt. ## 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 it's 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. --> 🆑 add: The darkness that glasses and hud goggles that impact your nightvision (think mesons, nightvision goggles, etc) lighten is now tinted to match the glasses. S pretty IMO, and hopefully it helps with forgetting you're wearing X. balance: Nightvision is darker. I think bright looks bad, and things like mesons do way too much balance: Mesons (and mobs in general) no longer have a static distance you can see stuff in the dark. If a tile is lit, you can now see it. fix: Nightvision no longer dims colored lights, instead simply thresholding off bits of darkness that are dimmer then some level. /🆑 |
||
|
MrMelbert
|
10f6825ae3 |
Updates policy to better warn players for any existing antagonist policy (#73408)
# Don't merge this without leading the headmins know so they can update the server configs ### For headmins: The following roles need to be updated: - "Obsession" -> `/datum/antagonist/obessed` - "Heretic" -> `/datum/antagonist/heretic` (Though this one will still work, change it to message them on spawn) - "Headslug Changeling" -> `/datum/antagonist/changeling/headslug` - "Pyroclastic Anomaly Slime" -> `/datum/antagonist/pyro_slime` (Though this one will still work, technically, change it to message them on spawn) ## About The Pull Request So, we have this whole system in the code to allow all mob typepaths, species typepaths, and even antag datum typepaths to have a set policy But we like, don't use it? For some reason we rather set a million `get_policy` calls than use this. They're all stuck in the policy verb and not sent to the player in any obvious. (Also, it's super fragile, which I hate. Change the typepath and the policy silently fails. Maybe someone can change that afterwards) This PR updates that. All antag datums will check in `on_gain` for policy to show to the player if there's any. It doesn't solve the entire issue. Mob policy and species policy is not conveyed to the player in any way BESIDES the policy verb which no one uses. So people have no idea that it's a thing. But it helps a bit. ## Why It's Good For The Game Better ways to convey to players how they should be playing. Also Valentines day, because... it's crazy. ## Changelog 🆑 Melbert config: Policy.json config got updated. The following values need to be updated: config: "Obsession" -> /datum/antagonist/obessed config: "Heretic" -> /datum/antagonist/heretic config: "Headslug Changeling" -> /datum/antagonist/changeling/headslug config: "Pyroclastic Anomaly Slime" -> /datum/antagonist/pyro_slime config: ALL antags in the policy.json file will now get notified of any existing policy set by the admin team, rather than only a handful. /🆑 --------- Co-authored-by: san7890 <the@san7890.com> Co-authored-by: Tim <timothymtorres@gmail.com> |
||
|
Zephyr
|
18b041bf47 |
Add logging for manually changing your targeted zone (#72814)
## About The Pull Request See title. Surgery hud is exempt from this. ## Why It's Good For The Game Requested by @Mothblocks ## Changelog Signed-off-by: GitHub <noreply@github.com> Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> Co-authored-by: dragomagol <66640614+dragomagol@users.noreply.github.com> |
||
|
Jeremiah
|
872e64fb05 |
Adds spaces around logical operators (#72603)
## About The Pull Request Part of a prior PR that was closed (#72562). This version does not add the check in CI. ## Why It's Good For The Game The work is already done, so I figured why not. ## Changelog N/A Nothing player facing Co-authored-by: Jeremiah Snow <jlsnow301@pm.me> Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
MrMelbert
|
c3a1f21c1a |
Converts blindness and nearsightedness to status effects, scratches some VERY dumb blindness handling that resulted in mobs becoming "incurably" blind (#72267)
## About The Pull Request - Nearsighted is now a grouped status effect. - Blindness is now a grouped status effect. - Eye handling of blindness has improved. - When eyes are removed, they now cause you to become blind, rather than handling it in `update_tint`. - Being ahealed no longer blinds you for one tick, meaning that black overlay on aheal is gone. - Temporary Blindness is now a status effect. - Both Nearsightedness and Blindness have been exorcised from mob vars and life chains. This means that we've finally cut 2 procs from life, `handle_status_effect` and `handle_traits`, and moved both to event based processing. Wooo optimizations. - Swapped pacifism status effect to use apply and set helpers. - Removed an unused admin toggle that disabled welding helmet tint but also tint from every clothing item and also blindness from losing your eyes. - Clothes now generally all blind their mob more consistently. - Oculine, eye surgery, and sensory restoration are now no longer the only way to fix blindness from eye damage. If your eyes are healed through any other means, it will also heal your blindness. - Some things that made you blind, such as ling blind sting, no longer just flat made you blind from eye damage forever. They now cause eye damage directly, which in turn makes you blind from eye damage, as expected. - Pacifists can't eyestab anymore. Eyestabs now have a limit on the amount of blur applied. - Refactored some `is_x_covered` procs to accept flags rather than have a lot of arguments for some silly reason. - Unit tests for blindness. ## Why It's Good For The Game Blindness was exceptionally poorly handled prior, primarily due to the fact that it was tied to the mob instead of separated out On top of that the system put a LOT of faith in proper handling of blindness on the coder's end which was misplaced evidently. Many places didn't update or handle blindness correctly, or just let people perma-blind. Deferring it to a status effect improves this a lot ## Changelog 🆑 Melbert refactor: Refactored blindness and nearsightedness. Important to note is that all mobs are naturally blind until their eyes are actually created. refactor: Refactored "is covered" procs fix: Less sources of blindness now cause permanent blindness. Includes the "Blind" Spell and "Blind Sting" from changelings. admin: Ahealing someone no longer flashes the blind overlay for 1 tick. admin: I removed an unused (sort of) inaccessible admin verb that allowed you to toggle the tint from all welding helmets (and clothing) (and lack of eyes) in existence, let me know if you want similar back balance: Changeling "Blind Sting" now causes eye damage (enough to blind) rather than arbitrarily forcing blindness. balance: Visionloss virus symptom now causes eye damage (enough to blind) rather than arbitrarily forcing blindness. balance: Oculine has been reworked slightly. Prior, Oculine arbitrarily healed blindness and nearsightedness from eye damage reagrdless of how damaged the eyes were, and applied blur on success. Now, Oculine just heals eye damage, and blindness / nearsightedness is restored in the process. There is now a probability every tick that eye blur is applied based on how pure the oculine is while healing very damaged eyes. balance: Pacifists can no longer eyestab. balance: Any clothing item that covers your eyes contributes to getting the bonus while sleeping, and to removing temporary blindness faster /🆑 |
||
|
Fikou
|
88de64a821 |
holopara qol update (#72042)
holoparasite types have improved code admins can now give someone a holoparasite through a new menu in vv dropdown alt click holopara abilities were moved to right click (support's beacon wasn't, but support's heal mode was) holoparas have less hardcoded stuff so admins can edit them easier holoparasites now get their light color from their guardian color holoparasites no longer have the hostile faction, things will attack them holoparasites now have a damage overlay, so you can see how much your summoner is damaged holoparasite health updating is now event based rather than running on life, so you'll see health changes everytime they happen, rather than every 2 seconds holoparasites fly properly again (they cant spacewalk, but count as flying for stuff like chasms) holoparasite creation now uses a radial menu with tooltips for each subtype. it also shows ghosts which type you picked holoparasites can no longer be fugu'd adds support for ownerless holoparasites fixes mildly related bugs along the way |
||
|
Dani Glore
|
a847f0970c |
Fix: Robotic Damage / Reagents Refactor (#71937)
## About The Pull Request This PR is a continuing refactor of and fixes bugs introduced by my prior PR #71864  Due to many functions in reagents having been implemented on top of prior buggy code, their new behaviors are not as expected in-game, and as a result reagents damage/heal robotic/cybernetic bodyparts/organs when not appropriate; bugs like healing robotic arms with Libital is currently possible. To fix the errant behaviors in the newly debugged code, I have added three variables to `datum/reagent` which are used throughout reagent code, mainly inside of `on_mob_life` etc: - `affected_bodytype = BODYTYPE_ORGANIC` - Used if the reagent damages/heals bodyparts (Brute/Fire) of an affected mob. - `affected_biotype = MOB_ORGANIC` - Used if the reagent damages/heals generic damage (Toxin/Oxygen) of an affected mob. - `affected_organtype = ORGAN_ORGANIC` - Used if the reagent damages/heals organ damage of an affected mob. The diff is large, and I have refactored the readability/maintainability around the sections of code I was modifying. At one point I chose to perform a quality pass on reagents because I found it quite hard to maintain reagents code in its current state. This PR also replaces many single-letter variables with more descriptive and readable variable names. I also found and fixed a stray tab which was located in the flavortext of `proc/item_heal_robotic` ## Why It's Good For The Game Due to an old bug being fixed recently by PR #71864 a lot of healing/damaging reagents now have an effect on robotic bodyparts. This PR corrects the issue and changes reagents to explicitly define the body type, bio type, and organ type which they can affect with helaing/damage. This PR replaces a lot of single-letter variable names with more descriptive names. I also fixed a small typo in `item_heal_robotic` which was inserting an extra tab. ## Changelog 🆑 fix: Fixed a stray-tab typo in "item_heal_robotic" fix: Fixed reagents and other effects which were inappropriately affecting robotic limbs. code: Refactored all of reagents code to be more readable and maintainable. /🆑 Co-authored-by: Time-Green <timkoster1@hotmail.com> |
||
|
itseasytosee
|
478a969cbb |
Delimbs Stamina (#71663)
## About The Pull Request This changes stamina damage from a damage that affects limbs (like brute and burn) to a damage that affects the body at whole (such as tox or oxy) Stamina being run like brute or burn is rooted all the way back to when it was halloss, and used exclusively for holodeck items and hallucinations. Most coders probably didn't even know that stamina worked like this, and most implimentatiosn of stmaina mechanics use a generic "adjust stamina" or a "apply_damage(type = stamina zone - body_zone_chest)" to avoid the issues that come when stamina is evenly distributed among limbs (and some limbs only count as a fraction to stamina damage total) The only thing that is truly lost here, is disabling limbs (arms and legs) with stamina damage, by aiming specifically at them with disablers (batons always apply their stamina damage to the chest, no matter where they hit) our through smashing limbs on tables. The idea of making an opponent drop a weapon out of pain is fun, but stamina doesn't support it, or make sense in context. A depth filled limb-based pain system that has interactions with painkillers and replaces damage based move slowdown would be fun, and maybe something that could be implemented in the future. ## Why It's Good For The Game The biggest draw here, is that it will make stamina easier to maintain ## Changelog 🆑 itseasytosee code: Stamina no longer affects individual limbs. /🆑 Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
|
tattle
|
ad5debaaa1 |
Add investigate_deaths (#71112)
## About The Pull Request Adds INVESTIGATE_DEATHS, an investigate category intended to better show causes of death.   Also makes suicide_act take a `mob/living` as an argument instead of a `mob`, and some minor style improvements since apparently I hate atomicity. ## Why It's Good For The Game Inspired by a mysterious death and dusting. More logging and leads for admins investigating deaths. Also fixes #59028 ## Changelog 🆑 Tattle admin: added investigate deaths to shed some more light on unusual demises, dustings, and gibbings /🆑 Co-authored-by: tattle <article.disaster@gmail.com> |
||
|
MrMelbert
|
6baebf47a1 |
Completely refactors hallucinations, and also adds a few (#69706)
* Refactors hallucinations slightly, organizes them * Refactors hallucination into a status effect * Further hallucination proper refactoring * Refactors battle hallucinations * Refactors "fake item other" hallucination * Gets it a bit closer to working state * Refactors screwydoll and fake alerts * Refactors fake inhand items * Refactors a few more. - Fake death - Fake messages - Fake sounds - Projectiles * Refactoring delusions, hallucination effects * Furthering the hallucination status effect - removes copypaste of hallucination pulses * Almost finalizes the changeover to status effect * Last staus effect stuff * Delusion business * Airlocks, fire, and more delusion stuff * Finishes screwyhud. It compiles now! * Swaps screwyhud over to a grouped status effect * Removes hal_screwyhud * Comment * Bugfixing * image cleaning * Get rid of this it came back * What if I finished this branch? * Oops * Messing with the randomness * Mass hallucination tweaks * + * Some more mass tweaks * Review * Updates * Unit tests hallucination icons * More tweaks * Move folder * Another re-name * Minor tweaks * Anomaly unity * Mass hallucination buffs * t * Sig * Merge * Lints * Unit test already coming in clutch * Another failure * Use named args for cause_hallucination via some define trickery * Some cleanup * This is better * adds some hallucinations * Oops * More sounds * Tweaks * Some additional documentation * Flash * Fixes mass hallucination * Json changes * Updates documentation * Json conflicts * Makes it work * Missed that one too * Helpers * More signalization (WIP) * Fixes bump * Missed a helper use * Dumb |
||
|
ShizCalev
|
b477a620e5 |
Limb targeting fix (#69405)
* makes targeting limbs work again |
||
|
ShizCalev
|
50f8a03502 |
Converts a bunch of things over to get_random_valid_zone() (#69331)
refactor: A bunch of things that used to not do anything (or just fall back on the chest) when targeting a limb that someone was missing will now be far more likely to attack another limb! |
||
|
ShizCalev
|
d31c681cfa |
Adds new mob helper for zones, get_random_valid_zone() (#69226)
ran_zone() returns all possible zones a mob CAN have, even if they've already lost the limb. This can result in attempting to target bodyparts that do not exist, and requires additional sanity checking (and in most cases, coders typically just default to targeting the chest which is boring.) This adds a helper that will now randomly pick from the zones/bodyparts that the mob DOES have, and return one of them. This'll allow a bit more dynamic functionality since you won't always fall back on the chest as a target. cl ShizCalev qol: Added a new mob helper complementary to ran_zone() called get_random_valid_zone(), which can only return zones/bodyparts that a mob DOES have. /cl |
