mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-08-17 18:19:16 +01:00
docker-build
1133
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
d14e538393 | Merge branch 'master' of https://github.com/tgstation/tgstation into upstream-15-10-2025 | ||
|
|
a2c7c8e57b |
Heretic Antagonist Full Overhaul. (#92119)
## About The Pull Request Heretic has received a complete overhaul. This PR touches nearly every aspect of the antagonist. For readability's sake, not every change is going to be listed in this pull request. For the full list of changes please refer to the design doc: https://hackmd.io/@BiST8PJVRjiwVPY86U3bLQ/B11HyChz1g. Code by Me, @Xander3359 and @Arturlang TGUI by @Arturlang Sprites by OrcaCora and GregorDM Writing bits by @necromanceranne ### Core changes - Cross-pathing has been removed. Main knowledge spells are now exclusive to their path (for the most part). - For every main knowledge unlocked (save for the robes and the blade upgrade), Heretics can choose one option from a draft of 3 random side knowledges (this is a free point). - Heretics can now purchase side knowledges from a new tab, the "Knowledge Shop". Side-knowledges have been divided by tier (Stealth, Defense, Summons, Combat and Main). Tiers are unlocked as you progress toward your main path. - Heretics now gain the grasp and mark upgrade immediately, but their main knowledge choices cost twice as much (except for the first spell, the robes and the blade upgrade). - Path specific robes have been introduced! They come with their own set of quirks. - Each Path has received a passive ability. This passive is upgraded when you first create your robes, and again when you complete the Ritual of Knowledge. - Paths have been rebalanced as a result of the removal of cross-path progression. Cosmic and Moon paths have received soft reworks. - Upon unlocking the path 2nd level or reaching a total of 8 points worth of knowledge, Heretics will lose the ability to blade break (and the limit on blades all together). - Ascension now automatically calls the shuttle with no possibility of a recall. - Late join Heretic has been removed. ### New UI <img width="750" height="635" alt="moon path ui" src="https://github.com/user-attachments/assets/184ef783-5c9c-48a1-a2f7-4807ca93e990" /> ### Knowledge shop <img width="787" height="669" alt="Knowledge shop" src="https://github.com/user-attachments/assets/3dc89b84-8c70-4d47-b612-54396e3ea6e7" /> ### Quality of life //General balance changes - Heretics will now gain X-ray vision for a few seconds when nearby an eldritch essence (this effect has a cooldown). - Ritual of knowledge now requires 1 uncommon item instead of 2. You may now use a stunprod instead of a baton to complete the ritual. Beartraps have been removed from the list of possible reagents. - The maximum number of possible sacrifices required to ascend has been reduced from 6 to 5 while the minimum has been upped to 4. - Codex Cicatrix no longer requires a special pen to be made. ### Passive abilities - Heretics now start with a passive ability. You can find what it does on the path info tab after a path has been selected, and what they gain when upgraded. - Crafting your first set of Eldritch robes will bump your passive to level 2. - Unlocking the 2nd level will subsequently unlock your "Ritual Of Knowledge" - Completing the ritual of knowledge or ascending will net you the final level. ### Path Specific Robes - Armorer's Ritual is no longer a side knowledge. Each path will have their own unique version of the ritual. This is placed after the 2nd spell in the tree. - Robes can no longer be destroyed by fire and acid, grant t4 flash protection (Moth Heretics stay winning) and protection against basic syringes, to bring them on par with other antagonist's armor sets. - The recipe to craft the robes is now a set of armor/vest, a mask (any mask will do now, not just gas masks), plus the unique reagent required for the blades (Plasma for Cosmic, Trash For Rust, match for Ash and so on) - Wearing the robes as a non-heretic may yield some unfortunate side-effects. ### Moon Path Rework Moon path rework. Moon Heretics gain immunity to brain traumas and slowly regenerate brain health. Equipping the moon amulette channels its effects through the moon blade; making it unblockable and cause sanity damage instead of brute. Ring leader's Rise now summons an army of harmless clones that explode when attacked; the explosion briefly stuns non-heretics and cause sanity and brain damage to them. Moon blade can also now be used when pacified and Moon spells are no longer blocked by regular anti magic, only mind magic protection. **Cosmic Path Rework** Cosmic path has received the biggest batch of changes alongside Moon. The path has been dead last in ascension and pickrate (less than 5%) for almost 2 years. It did gain some popularity over the last few months, reaching the highest ascension rate in the game (12%) while mantaining a relatively low pickrate. Cosmic sits in a weird spot, where pretty much every knowledge surrounding the path is either mediocre or, in the case of the ascension, dysfunctional. Yet it has maintained a smidge of relevancy due to how quickly Cosmic heretics can capture and sacrifice targets thanks to Star Touch. As a result, the best course of action would be to rebalance the entirety of the kit; granting the heretic more tools to manipulate space and dictate the flow of a fight, while lessening their ability to end a confrontation by instantly sleeping their opponents. lastly The Star Gazer is now ghost controlled ; And they shoot lazers! <img width="636" height="451" alt="gazer gag 3" src="https://github.com/user-attachments/assets/601d6881-c042-4e42-8ce6-ac90cd27848b" /> ## Why It's Good For The Game ### Ok...but why do we want this? Again, if you want my full reasoning, please check my doc https://hackmd.io/@BiST8PJVRjiwVPY86U3bLQ/B11HyChz1g. To keep it short and concise; Heretic is too complex and unintuitive for its own good. Too impenetrable for new players and too abusable for experienced players. This can be chalked up to a lot of poor design decisions. But ultimately, what I believe being the biggest contributor to the current status of Heretic is the ability to move into different paths, also known as "Cross-Pathing". ### Cross Pathing my beloathed. Cross-pathing, while cool in theory, overcomplicates the antagonist and overloads them with power. Players dealing with the heretic are incapable of working out what a given heretic can do. This also leads to late game heretics having 3 rows Worth of action buttons and virtually no weakness. Over the last year, I've often received the understandable but also kind of unfair accusations of making Heretic too powerful without a clear aim or purpose. My goal with the paths I've reworked over the last year (Rust,Void and Blade) wasn't necessarily to just make them stronger (although that was also part of the goal, as they were paths that were underperforming), but for them to have more interactions with the sandbox and to better live up to the fantasy presented to the player. If an harbringer of frost gets countered by a cup of coffee, we probably messed something up. Unfortunately, the current incarnation of Heretic doesn't really allow for surgical balance changes to specific paths. Every time a knowledge gets buffed, we make every path that can easily tap onto that knowledge stronger by default. It doesn't take a genius to understand why this system is ultimately unsustainable. ### Blade Breaking I feel that after a heretic has reached the near peak of their power, they no longer need the ability to instantly escape any encounter. Check my doc for my full reasoning. ## Less versatile, more specialized paths. By removing cross-pathing, we remove a huge maintainability burden from the antagonist. Paths can now be designed around clearer strengths and weaknesses. They become easier to balance and less of an headache to understand for everyone. It also means we can give paths some needed quality of life quirks without having to worry how such a change might have a knock-on effect for other paths. Ash heretics can finally let loose without dying by their own flames. Cosmic Heretic can go to space without having to carry a modsuit. Moon Heretic can use their abilities without fear of one random trauma ruining their day, and so on. ### What a horrible night to have a curse...., wait how do I curse people again? As of right now the heretic tree has quite a hefty amount of trinkets that pretty much never see use. Partly because the tree itself is a nightmare to navigate. And partly because why would anyone set up an elaborate plan or scheme when they can unleash 2 rows of spell in the span of bunch of seconds. Heretics mostly gravitate towards powers that push them towards greater, more potent combat strength. If it doesn't contribute to killing people quicker, it isn't worth doing for most. And given the opportunity cost associated for taking those powers, they will remain that way so long as there are better choices to be poached. The new draft system encourages Heretics to play more with the tools at their disposal. If you want to go for a specific combo from the side path options, you may now do so by tapping into the knowledge shop. Yes, the shop does include a few knowledges from the other paths. But these are limited to 1 per path, are very expensive and can only be unlocked very late into the shift. ## Drip Of the Mansus The iconic heretic robe is actually sequestered to a side path that is most easily access by only two paths at a time. Since heretic paths are being made to be much more specialized, the most obvious way in which this can be showcased is through an easily identifiable outfit. By using the robes, we can both telegraph WHAT heretic you are looking at, and just how much power they've accumulated and when it is reasonable to take the kid gloves off and treat them as a genuine threat. If a heretic is in their robes, that heretic is now a significantly more prominent danger to the station. It also serves as a useful means for gating some of the more powerful effects of a heretic's path behind the robes, AND enable options for disarming them of that power should they be captured without making it something endemic to their mob. A major problem with heretics is a lack of certainty as to how powerful they have become. A heretics robes is one of the milestones to help players dealing with heretics identify that. ### Will this be 100% fair and balanced? This is a massive overhaul to a pretty complex and bloated antagonist. I've done my best to show the changes to several maintainers and other members of the community for their feedback. But at some point we'll have to see how this behave in the environment to get a feel if something is over or undertuned. (that's my way of saying, yes this is likely gonna require a testmerge or two). What I will say is that I'm not trying to change the core identity of Heretic. Heretics should have the upperhand in single encounters early on, be able to joust a small group of players after they unlock their final spell, and end the round when they ascend. They're a progression antagonist. They should retain their payoff as well as pose a danger as they grow stronger. But if more players feel like they are more reliably able to play the antagonist in more varied and interesting ways, rather than the antagonist largely existing as a measuring stick for 'robustness' due to its elitist design philosophy, then the rework has been a success. There should be something for everyone in the antagonist, as is true for all of our antagonist roles. |
||
|
|
da10322dc1 |
Fix modsuits and defibs (#93373)
## About The Pull Request Fixes #93359 Caused by #93165 Inventory screen elements were no longer considered reachable, which broke mousedrop handing on objects that check "is dragging into inventory slot" I don't know the best way to fix this yet but I figured the next best thing would be to make all of these use the `drag_pickup` element, which skips this reach-ability check Thus I refactored it slightly to accommodate for items which should contextually not be drag-pick-up-abble and bam, works like a charm ## Changelog 🆑 Melbert fix: Dragging defibs and modsuits off your back works again /🆑 --------- Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com> Co-authored-by: Xander3359 <66163761+Xander3359@users.noreply.github.com> |
||
|
|
5e629dff04 | Merge branch 'master' of https://github.com/tgstation/tgstation into upstream-sync | ||
|
|
751fcb5f16 |
Add more examine tags and fix ones not appearing (#93110)
## About The Pull Request This fixes custom materials not appearing for things like structures. It also adds a bunch of new tags: - bomb-proof - flammable - holograhic - ~~unpaintable~~ - ~~supermatter proof~~ - ~~recolorable~~ - crush-proof - conductive Also use hyphens for multi-word examine tags. ## Why It's Good For The Game Better UX ## Changelog 🆑 qol: Add several new examine categories for objects descs that include: bomb-proof, flammable, holograhic, crush-proof, and conductive. Also use hyphens for multi-word examine tags. fix: Fixes custom materials not appearing for things like structures when examined. /🆑 |
||
|
|
9b282a850e | Merge branch 'master' of https://github.com/tgstation/tgstation into upstream-sync | ||
|
|
d2f34e33be |
moves abstract_type up to datum, spawners wont spawn them (#92909)
## About The Pull Request moves all implementations (im aware of) for "Im a parent type dont spawn me please" to the datum layer to standardized behavior adds a standerized proc for filtering out "bad" items that we dont want spawning. applies to it the subtype vendor, gifts, and a new spawner and mystery box for a random gun (neither playerfacing) "port" of https://github.com/shiptest-ss13/Shiptest/pull/4621 https://github.com/user-attachments/assets/22f6f0b2-b44e-411a-b3dc-6b97dc0287aa small warning: I dont have EVERY abstract type defined right now but, ive done a good enough job for now. Im tired of data entry rn ## Why It's Good For The Game standardizing behavior. Might be a micro hit to performance however having this lets us not rely on icon state to determine whether something is a parent type and makes it much easier to tell something is a parent type (could be applied further to things like admin spawning menus and things like that). need feedback on if this is actually good for the game. ## Changelog 🆑 add: Soda cans show up in the silver slime drink table. add: Examine tag for items that are not mean to show up ingame. refactor: Standardizes how gifts rule out abstract types. fix: gifts no longer check if something has an inhand, massively expanding the list of potential items. /🆑 |
||
|
|
939f2fc9ac | Merge branch 'master' of https://github.com/tgstation/tgstation into xpokee-test-upstream-sync | ||
|
|
135a09182b |
Refactors obscured (#92779)
## About The Pull Request Fixes #85028 Obscured flags and covered flags are tracked on carbons, updated as items are equipped and unequipped. It's that shrimple. Closes #92760 Just removes the species exception checks for not making sense Also refactors handcuffs / legcuffs removal. In all of these situations they were hardcoded when they could easily just use an inventory proc to work. ## Why It's Good For The Game Stops a million excessive calls to `check_obscured_slots` Makes obscured behavior more consistent Makes obscured behavior easier to use Cleans up human rendering (There was some cursed stuff before with render item -> updated obscured -> update body -> cause side effects) ## Changelog 🆑 Melbert del: Golems which somehow manage to grow wings and somehow manage to equip something that covers their jumpsuit can no longer fly. (Seriously, this will not affect anyone) refactor: Refactored clothing obscurity entirely. Items should be a loooot more consistent and what covers what, and should update a lot snappier. As always, report any oddities, like mysteriously disappearing articles of clothing, hair, or species parts refactored: Refactored handcuffs and legcuffs a bit, report any odd situations with cuffs like getting stuck restrained /🆑 |
||
|
|
b348b617a3 |
Merge branch 'master' of https://github.com/tgstation/tgstation into pupstream-2025-09-07
# Conflicts: # README.md # code/__DEFINES/admin.dm # code/__DEFINES/melee.dm # code/_globalvars/traits/_traits.dm # code/controllers/subsystem/economy.dm # code/datums/components/crafting/crafting.dm # code/datums/elements/crusher_loot.dm # code/modules/antagonists/pirate/pirate_shuttle_equipment.dm # code/modules/clothing/suits/_suits.dm # code/modules/escape_menu/leave_body.dm # code/modules/jobs/job_types/_job.dm # code/modules/mining/equipment/mineral_scanner.dm # code/modules/mob/living/living.dm # code/modules/plumbing/plumbers/pill_press.dm # tgui/packages/tgui/interfaces/Vending.tsx |
||
|
|
697bdea143 |
The speed of tools used in a crafting recipe now affect the time spent on it (#92577)
## About The Pull Request Title. Using better tools should now make crafting faster (or lower) depending on the quality of the tools. This affects roughly 85% of the crafting time, so, for every second of it, you're guaranteed to spend 0.15 seconds even if your tools are fast as light itself. Also a nit with the main benefit of the mining skill being locked to humans despite it being bound to the mind datum. ## Why It's Good For The Game Tool speed previously didn't play a role in crafting. Now it does. ## Changelog 🆑 balance: The speed of tools used in a crafting recipe now affect the time spent on it. Report any recipe that takes awfully little or too long to complete. balance: Non-humanoid mobs can now benefit from being skilled at mining when swinging that pickaxe. /🆑 |
||
|
|
72337c8359 |
Prevents "Move To Top" verb from working on anchored objects (#92692)
## About The Pull Request We use items as structures due to stupid code in a few places (intercoms, for once) and this verb can cause weird/broken behavior on them. Doesn't make sense from an IC perspective either. Closes #92671 ## Changelog 🆑 fix: "Move To Top" verb no longer destroys wall-mounted intercoms /🆑 |
||
|
|
20118ad747 |
Converts a bunch of time/delay vars to use time defines (#92495)
## About The Pull Request Converts as many time vars expressed in deciseconds as I could find to use time defines. ## Why It's Good For The Game Makes these values neater and more readable. ## Changelog 🆑 code: Converted a lot of time-based variables to be expressed with time defines. /🆑 # Conflicts: # code/modules/clothing/head/hat.dm # code/modules/clothing/shoes/boots.dm # code/modules/clothing/suits/utility.dm |
||
|
|
7497b05ab1 |
lazily initialize /datum/element/weapon_description on examine (#92489)
## About The Pull Request currently, `/datum/element/weapon_description` is added during every single item init, even tho it only ever affects examines. i noticed while looking at tracy traces downstream that it spent a bit much time adding the weapon description, so why not just lazily initialize it during examine instead? direct port of the same thing from https://github.com/Monkestation/Monkestation2.0/pull/7502 ## Why It's Good For The Game less wasted time during item init ## Changelog 🆑 code: Item weapon description elements are now initialized when first examined, instead of immediately upon initialization. /🆑 |
||
|
|
260960d6f4 |
Converts a bunch of time/delay vars to use time defines (#92495)
## About The Pull Request Converts as many time vars expressed in deciseconds as I could find to use time defines. ## Why It's Good For The Game Makes these values neater and more readable. ## Changelog 🆑 code: Converted a lot of time-based variables to be expressed with time defines. /🆑 |
||
|
|
f4fe6c46a7 |
lazily initialize /datum/element/weapon_description on examine (#92489)
## About The Pull Request currently, `/datum/element/weapon_description` is added during every single item init, even tho it only ever affects examines. i noticed while looking at tracy traces downstream that it spent a bit much time adding the weapon description, so why not just lazily initialize it during examine instead? direct port of the same thing from https://github.com/Monkestation/Monkestation2.0/pull/7502 ## Why It's Good For The Game less wasted time during item init ## Changelog 🆑 code: Item weapon description elements are now initialized when first examined, instead of immediately upon initialization. /🆑 |
||
|
|
16aa15a136 |
Changes human name updates to be request-based instead of being automatically done every single tick (#92393)
## About The Pull Request
Changes human name to update whenever anything that could result in
their visible name changing occurs, such as changing IDs, equipping
gasmasks, picking potted plants, etc. Currently name updates occur every
``Life()`` tick and in a few "special" cases, which causes a lot of name
changes from sources such as equipment to not apply until the mob ticks,
and makes us waste a tiiiny bit of CPU time on name updates.
I've also slighly cleaned up human /Life() and made species'
``spec_life()`` not run when the mob is dead, as it was causing certain
unintended interactions, such as slimepeople regenerating blood while
dead.
## Why It's Good For The Game
Microoptimization, ensures that correct names are always used (in case
something could update their name but the mob hasn't ticked yet), plus
its just a cleaner implementation
(cherry picked from commit
|
||
|
|
87e1ef6f64 |
Changes human name updates to be request-based instead of being automatically done every single tick (#92393)
## About The Pull Request Changes human name to update whenever anything that could result in their visible name changing occurs, such as changing IDs, equipping gasmasks, picking potted plants, etc. Currently name updates occur every ``Life()`` tick and in a few "special" cases, which causes a lot of name changes from sources such as equipment to not apply until the mob ticks, and makes us waste a tiiiny bit of CPU time on name updates. I've also slighly cleaned up human /Life() and made species' ``spec_life()`` not run when the mob is dead, as it was causing certain unintended interactions, such as slimepeople regenerating blood while dead. ## Why It's Good For The Game Microoptimization, ensures that correct names are always used (in case something could update their name but the mob hasn't ticked yet), plus its just a cleaner implementation |
||
|
|
a0c3a97d94 | Fixes equipping items onto other people playing swing animations (#92104) | ||
|
|
d8011967e1 | Fixes equipping items onto other people playing swing animations (#92104) | ||
|
|
24c2d1e530 |
Refactor how most of the item sound handling is handled (#91921)
## About The Pull Request turns most of the item sound handling into procs instead of calling playsound directly - added support for changing the pickup, drop, throw_drop, mob_throw_hit, equip when a reagent container is filled up to 20% of it's reagent capacity. ## Why It's Good For The Game we turn these into procs so we can override them on subtypes, this allows us to do some funky stuff, for example play reagent sloshing sounds together with other sounds on different interactions for reagent_containers, allowing us, for example to play reagent sloshing sounds when hitting someone with a beer bottle, or extinguisher. or, in the future we can play chafing sounds for clothes on sound handling when they are damaged enough. ## Changelog 🆑 refactor: changed how sound handling for item sounds works, report any sounds not making any sounds! sound: handling reagent containers around will play their reagent sloshing sounds more often /🆑 |
||
|
|
48323af265 |
Refactor how most of the item sound handling is handled (#91921)
## About The Pull Request turns most of the item sound handling into procs instead of calling playsound directly - added support for changing the pickup, drop, throw_drop, mob_throw_hit, equip when a reagent container is filled up to 20% of it's reagent capacity. ## Why It's Good For The Game we turn these into procs so we can override them on subtypes, this allows us to do some funky stuff, for example play reagent sloshing sounds together with other sounds on different interactions for reagent_containers, allowing us, for example to play reagent sloshing sounds when hitting someone with a beer bottle, or extinguisher. or, in the future we can play chafing sounds for clothes on sound handling when they are damaged enough. ## Changelog 🆑 refactor: changed how sound handling for item sounds works, report any sounds not making any sounds! sound: handling reagent containers around will play their reagent sloshing sounds more often /🆑 |
||
|
|
78cffc2101 |
Adds a new halloween species: Spirits (#90711)
Adds 2 new species: Spirits and Ghosts
Spirits are available roundstart during Halloween, Wabbajack and
Xenobio's black slime extract
Ghosts are available through Magic mirrors
They fly around, and don't have legs and instead float around. They also
can't get legs implanted onto themselves.
They also do have organs, so they are affected by flashbangs, they do
get hungry, they do need oxygen to survive (they don't take damage in
space but they do suffocate & get slowdown), and can process chems.
Gibbing a ghost gives ectoplasm, an ingredient for ghost burgers.
Chaplains also got a buff here, null rod-type weapons' bane is now
against Spirit mobs, rather than hardcoded revenants. This means it now
includes Spirits/Ghosts, but also Soulscythes & Cult shades.
Also re-adds https://github.com/tgstation/tgstation/pull/81630 which was
reverted in https://github.com/tgstation/tgstation/pull/86506 which I
assume was accidental.
Ghosts have an innate ability to become incorporeal, which allows them
to phase through walls and stuff. Using this will immediately make them
drop any non-ghost limb/organ (not implants cause I thought it would be
funny). This ability is not available if they have holy water in their
system, and like revenants they also can't walk over blessed tiles with
it. They are also invisible to cameras while using this (not the obscura
though).
Sprites taken from observers directly, if anyone wants to make custom
sprites for them feel free. If anyone wants to make this obtainable
somehow in-game as well I wouldn't be opposed, halloween is just where I
thought it would fit most.
This also adds a lot of fixes that I encountered trying to add this,
from systems that have been neglected throughout the years.
https://github.com/user-attachments/assets/e368d710-80a0-4c63-b271-1abe3dd41a5e
We haven't gotten a new halloween species in a long time and thought it
would be fun if you can play as an actual ghost, the soul that remains
after a person passes, so Halloween feels more haunted. It's overall
made in just good fun, with a bonus that Ghosts are a cool species to
play with as well for Wizards & maybe Chaplains in the future (Dead sect
when?)
🆑
add: Added a new halloween species: Spirits, a species without legs and
instead floats.
add: Added a new magic mirror species: Ghosts, like spirits but with the
ability to become incorporeal, traversing through solid wall.
fix: Mobs unable to use storage items now can't use storage items.
fix: Mobs unable to use items can now not open airlocks & closets
fix: Mobs unable to pick items up can no longer pick items up and
immediately drop, moving one tile at a time.
fix: Mobs with intentional missing limbs (Alien larva) no longer show
their limbs as missing on examine (again)
fix: Golems' pref page had a missing icon, it now has one.
/🆑
---------
Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com>
(cherry picked from commit
|
||
|
|
096c032402 |
Adds a new halloween species: Spirits (#90711)
## About The Pull Request Adds 2 new species: Spirits and Ghosts Spirits are available roundstart during Halloween, Wabbajack and Xenobio's black slime extract Ghosts are available through Magic mirrors They fly around, and don't have legs and instead float around. They also can't get legs implanted onto themselves. They also do have organs, so they are affected by flashbangs, they do get hungry, they do need oxygen to survive (they don't take damage in space but they do suffocate & get slowdown), and can process chems. Gibbing a ghost gives ectoplasm, an ingredient for ghost burgers. Chaplains also got a buff here, null rod-type weapons' bane is now against Spirit mobs, rather than hardcoded revenants. This means it now includes Spirits/Ghosts, but also Soulscythes & Cult shades. Also re-adds https://github.com/tgstation/tgstation/pull/81630 which was reverted in https://github.com/tgstation/tgstation/pull/86506 which I assume was accidental. ### The difference between Spirits and Ghosts Ghosts have an innate ability to become incorporeal, which allows them to phase through walls and stuff. Using this will immediately make them drop any non-ghost limb/organ (not implants cause I thought it would be funny). This ability is not available if they have holy water in their system, and like revenants they also can't walk over blessed tiles with it. They are also invisible to cameras while using this (not the obscura though). Sprites taken from observers directly, if anyone wants to make custom sprites for them feel free. If anyone wants to make this obtainable somehow in-game as well I wouldn't be opposed, halloween is just where I thought it would fit most. This also adds a lot of fixes that I encountered trying to add this, from systems that have been neglected throughout the years. https://github.com/user-attachments/assets/e368d710-80a0-4c63-b271-1abe3dd41a5e ## Why It's Good For The Game We haven't gotten a new halloween species in a long time and thought it would be fun if you can play as an actual ghost, the soul that remains after a person passes, so Halloween feels more haunted. It's overall made in just good fun, with a bonus that Ghosts are a cool species to play with as well for Wizards & maybe Chaplains in the future (Dead sect when?) ## Changelog 🆑 add: Added a new halloween species: Spirits, a species without legs and instead floats. add: Added a new magic mirror species: Ghosts, like spirits but with the ability to become incorporeal, traversing through solid wall. fix: Mobs unable to use storage items now can't use storage items. fix: Mobs unable to use items can now not open airlocks & closets fix: Mobs unable to pick items up can no longer pick items up and immediately drop, moving one tile at a time. fix: Mobs with intentional missing limbs (Alien larva) no longer show their limbs as missing on examine (again) fix: Golems' pref page had a missing icon, it now has one. /🆑 --------- Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> |
||
|
|
690bfc04b4 |
Rebalances wound determination values, wounding escalation and wound armor to hopefully be less explosive (#91099)
This is a big one so please bear with me, wounds are complicated We've decreased the max contributed damage to wound rolls from 35 to 25. This results, after the exponent, a max possible wound roll of 1 to 91 before any modifiers (assuming the attack, after armor, is 25 or above). The minimum value to wound is still 5. Most wounds were contributing significant numbers per wound type to the potential for a new wound to occur. Getting wounded once meant you were getting wound a lot, but actually getting past that first wounding may be the tricky part. We have significantly reigned in the wound penalty that having a wound contributes, and instead utilize the series wound penalty to allow same type wounds to escalate themselves faster as a priority. Having wounds still makes you more wound vulnerable, just not to such an extreme degree. The priority here for what wounds matter most for contributing to overall wounding vulnerability is ``Infected BURNS > BURNS > SLASH|PIERCE > BLUNT.`` Wound armor, unlike all other kinds of armor, was used as a additive value to the wound roll modifiers rather than a multiplicative value. We have reworked how wound armor is determined by changing how wound modifiers are calculated. Firstly, we're passing our entire injury roll into the ``check_woundings_mod()`` proc, as we're not treating this as a proc that just adds values anymore. Secondly, bare wound bonus only applies if there is no potential wound protection from any source, as expected. But it comes last in the calculations. Thirdly, wound protection is applied to the injury roll last, after wound bonuses from the attack, wound bonuses from other wounds and wound bonuses from a disabled limb are applied. This does not include serial wound bonuses, which are determined outside of this proc. Wound protection comes from two sources. Clothing and limb wound resistance. Your chest and head have an amount of wound resistance so long as they are not mangled in any fashion. Being mangled means having either a hairline fracture or a weeping avulsion wound. Wound protection reduces the final injury roll by a percentage. Say our roll is 50, and we have effectively 50% wound protection. The final roll would be 25. ~~Most clothing have had their wound armor values changed. As a loose rule, I used the highest of melee or bomb armor, except where that value was 100, in which case I used the lowest instead. I'm basing this decision on how embeds are calculated, which is attack type agnostic.~~ ~~Some armor have inconsistent values because they are alternative armors to an existing armor type or are hyperspecialized armor. Ablative, bulletproof and security vests all share a value of 35, despite the former two not having decent melee or bomb armor.~~ ~~Some clothing missing wound armor that should have had them now have wound armor.~~ ~~This may need a bit of scrutiny in case one or two seem weirdly high. Some have maybe become too low. Its a bit hard to say.~~ I changed it to ``exposed_wound_bonus`` to better represent when it applies. You can be naked and still not be affected by this bonus if the limb has wound resistance. I'm not promising anything with this PR, but this is an attempt to sanity check the values on wounds so that we're not seeing what the data that determined the removal of beheading presented. An extreme over-representation of tier 3 wounds. ~~And, from that, maybe I can argue for beheadings coming back. That's my goal. I think beheadings happened so much because the numbers were in need of work.~~ Well okay I just wanna make wounds a bit more workable actually more than I want beheadings. Why is it that tier 3 wounds were so over-represented? Because wounds will often force more severe wounds of other types by merit of any wounds existing at all on a limb. Having **_a_** wound makes you more wound prone for any kind of wound, and not just making you more likely to suffer a more severe type of the same wound. The threshold mechanic was intended to simulate making a wound worse, but oddly just made a limb broadly more prone to getting worse from any kind of attack to such a degree that future wound rolls of different types were often going to start at the threshold necessary to be a tier 3 wound. Dismemberment, mind you, requires you to suffer a flesh wound while you have a bone wound of tier 2 or higher (with tier 3 giving a bonus to this). You can do this readily via just a sharp weapon, because having a mangled limb causes the wound to turn into a bone wound. Technically, this is meant to be less likely as the effective damage for this wound is halved. But the wound bonus from having a flesh wound was almost always significant enough to kick your new bone wound up to a tier 3. In other words; its not surprising that you saw so many beheadings, because the system wanted to behead you as fast as it possibly can thanks to all these escalating values. Wound armor was only applied as a flat reduction on the roll. The average for wound armor was 10. After receiving a single wound, you can expect wound rolls to reach upwards of 100, even if the actual damage roll was not particularly high, due to wound stacking bonuses form being wounded. This meant that wounds, if they happened, came thick and fast after the first, regardless of what your protection might be to wounds. It was just a matter of getting past the initial bump. This is why effects that forced wounds were so powerful. They basically made a given limb more prone to taking a wound without having to deal with the protection problem first. Finally, this is just a broad flaw with the system that is not its fault. It is actually a problem that isn't a problem. Most people in the game are not wearing helmets that protect their head. So most people are going to suffer from a higher proclivity of being wounded if people are aiming for the head. There is this...kind of cargo cult belief that aiming for the head means you do more damage, or can stun someone if you're lucky or what have you. It's entirely nonsense, but it has a grain of truth in that people rarely wear, or even have access too, headwear that provides wound protection or any protection at all. People have jumpsuits, which are universally wound protected, but that isn't true of the head. Look, the point is, they're not aiming at the head because it is usually less armored, its for other reasons but it just so happens to become true due to wounds and how wounds roll their type. To soften this issue, I've decided to treat wound resistance as armor until the limb suffers a tier 3 wound. This way, hits to the head MAY not necessarily escalate to tier 3 instantly as they would on live even from relatively low power weapons. Some weapons have very low force, but have extreme bare wound bonuses. This should be less likely after this change. I doubt this will necessarily make high damage high wound weapons like energy swords any less prone to cutting you clean open, but it might thanks to the reduction to contributed damage to the injury roll. The system is now _a bit more random_. 🆑 balance: Wounds do not make you as vulnerable to suffering wounds of all types as before. Instead, wounds make you more vulnerable to suffering worse versions of themselves as a priority. balance: Wound armor is now more impactful when protecting you from wounds when you have already been wounded. balance: Your head and chest are more difficult to wound until they have been mangled; either from suffering from a weeping avulsion or a hairline fracture. code: Changed the variable for bare_wound_bonus to exposed_wound_bonus to better explain what that variable is doing. /🆑 --------- Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com> |
||
|
|
57624ca1e2 |
Rebalances wound determination values, wounding escalation and wound armor to hopefully be less explosive (#91099)
## About The Pull Request This is a big one so please bear with me, wounds are complicated ### Max Potential Wound Rolls We've decreased the max contributed damage to wound rolls from 35 to 25. This results, after the exponent, a max possible wound roll of 1 to 91 before any modifiers (assuming the attack, after armor, is 25 or above). The minimum value to wound is still 5. ### Wound Escalation Penalties Most wounds were contributing significant numbers per wound type to the potential for a new wound to occur. Getting wounded once meant you were getting wound a lot, but actually getting past that first wounding may be the tricky part. We have significantly reigned in the wound penalty that having a wound contributes, and instead utilize the series wound penalty to allow same type wounds to escalate themselves faster as a priority. Having wounds still makes you more wound vulnerable, just not to such an extreme degree. The priority here for what wounds matter most for contributing to overall wounding vulnerability is ``Infected BURNS > BURNS > SLASH|PIERCE > BLUNT.`` ### Wound Armor Wound armor, unlike all other kinds of armor, was used as a additive value to the wound roll modifiers rather than a multiplicative value. We have reworked how wound armor is determined by changing how wound modifiers are calculated. Firstly, we're passing our entire injury roll into the ``check_woundings_mod()`` proc, as we're not treating this as a proc that just adds values anymore. Secondly, bare wound bonus only applies if there is no potential wound protection from any source, as expected. But it comes last in the calculations. Thirdly, wound protection is applied to the injury roll last, after wound bonuses from the attack, wound bonuses from other wounds and wound bonuses from a disabled limb are applied. This does not include serial wound bonuses, which are determined outside of this proc. Wound protection comes from two sources. Clothing and limb wound resistance. Your chest and head have an amount of wound resistance so long as they are not mangled in any fashion. Being mangled means having either a hairline fracture or a weeping avulsion wound. Wound protection reduces the final injury roll by a percentage. Say our roll is 50, and we have effectively 50% wound protection. The final roll would be 25. ### ~~Wound Armor on Clothing~~ Reverted ~~Most clothing have had their wound armor values changed. As a loose rule, I used the highest of melee or bomb armor, except where that value was 100, in which case I used the lowest instead. I'm basing this decision on how embeds are calculated, which is attack type agnostic.~~ ~~Some armor have inconsistent values because they are alternative armors to an existing armor type or are hyperspecialized armor. Ablative, bulletproof and security vests all share a value of 35, despite the former two not having decent melee or bomb armor.~~ ~~Some clothing missing wound armor that should have had them now have wound armor.~~ ~~This may need a bit of scrutiny in case one or two seem weirdly high. Some have maybe become too low. Its a bit hard to say.~~ ### The ``bare_wound_bonus`` variable I changed it to ``exposed_wound_bonus`` to better represent when it applies. You can be naked and still not be affected by this bonus if the limb has wound resistance. ## Why It's Good For The Game I'm not promising anything with this PR, but this is an attempt to sanity check the values on wounds so that we're not seeing what the data that determined the removal of beheading presented. An extreme over-representation of tier 3 wounds. ~~And, from that, maybe I can argue for beheadings coming back. That's my goal. I think beheadings happened so much because the numbers were in need of work.~~ Well okay I just wanna make wounds a bit more workable actually more than I want beheadings. Why is it that tier 3 wounds were so over-represented? Because wounds will often force more severe wounds of other types by merit of any wounds existing at all on a limb. Having **_a_** wound makes you more wound prone for any kind of wound, and not just making you more likely to suffer a more severe type of the same wound. The threshold mechanic was intended to simulate making a wound worse, but oddly just made a limb broadly more prone to getting worse from any kind of attack to such a degree that future wound rolls of different types were often going to start at the threshold necessary to be a tier 3 wound. Dismemberment, mind you, requires you to suffer a flesh wound while you have a bone wound of tier 2 or higher (with tier 3 giving a bonus to this). You can do this readily via just a sharp weapon, because having a mangled limb causes the wound to turn into a bone wound. Technically, this is meant to be less likely as the effective damage for this wound is halved. But the wound bonus from having a flesh wound was almost always significant enough to kick your new bone wound up to a tier 3. In other words; its not surprising that you saw so many beheadings, because the system wanted to behead you as fast as it possibly can thanks to all these escalating values. Wound armor was only applied as a flat reduction on the roll. The average for wound armor was 10. After receiving a single wound, you can expect wound rolls to reach upwards of 100, even if the actual damage roll was not particularly high, due to wound stacking bonuses form being wounded. This meant that wounds, if they happened, came thick and fast after the first, regardless of what your protection might be to wounds. It was just a matter of getting past the initial bump. This is why effects that forced wounds were so powerful. They basically made a given limb more prone to taking a wound without having to deal with the protection problem first. Finally, this is just a broad flaw with the system that is not its fault. It is actually a problem that isn't a problem. Most people in the game are not wearing helmets that protect their head. So most people are going to suffer from a higher proclivity of being wounded if people are aiming for the head. There is this...kind of cargo cult belief that aiming for the head means you do more damage, or can stun someone if you're lucky or what have you. It's entirely nonsense, but it has a grain of truth in that people rarely wear, or even have access too, headwear that provides wound protection or any protection at all. People have jumpsuits, which are universally wound protected, but that isn't true of the head. Look, the point is, they're not aiming at the head because it is usually less armored, its for other reasons but it just so happens to become true due to wounds and how wounds roll their type. To soften this issue, I've decided to treat wound resistance as armor until the limb suffers a tier 3 wound. This way, hits to the head MAY not necessarily escalate to tier 3 instantly as they would on live even from relatively low power weapons. Some weapons have very low force, but have extreme bare wound bonuses. This should be less likely after this change. I doubt this will necessarily make high damage high wound weapons like energy swords any less prone to cutting you clean open, but it might thanks to the reduction to contributed damage to the injury roll. The system is now _a bit more random_. ## Changelog 🆑 balance: Wounds do not make you as vulnerable to suffering wounds of all types as before. Instead, wounds make you more vulnerable to suffering worse versions of themselves as a priority. balance: Wound armor is now more impactful when protecting you from wounds when you have already been wounded. balance: Your head and chest are more difficult to wound until they have been mangled; either from suffering from a weeping avulsion or a hairline fracture. code: Changed the variable for bare_wound_bonus to exposed_wound_bonus to better explain what that variable is doing. /🆑 --------- Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com> |
||
|
|
c906b85d30 |
Audits wash/cleaning signals + refactors wash() to ensure no needless mob updates occur (#91259)
## About The Pull Request This has the potential to create a lot of needless mob updates which is not great. Now should only update a mob's clothing if it was actually washed. This PR 1) ensures that all wash() procs return a bitflag. 2) ensures that `wash()` proccalls which result in expensive operations like icon updates only do so when it is necessary ## Why It's Good For The Game Updating mob sprites is expensive, and doing it when nothing has been changed is bad. ## Changelog Nothing really player facing |
||
|
|
3c1505ac06 |
Cyborgs now use storage datum (#90927)
This moves Cyborgs onto using storage datums, removing the remenants of the shitcode that was Cyborg inventory. It's now done mostly by equipping/unequipping/storage items, much like how other mobs do. This allows borgs to take advantage of more hand support stuff and things like ``dropped()``, so borgs no longer have to copy paste drop code to ``cyborg_unequip`` It also: - Removes ``CYBORG_ITEM_TRAIT`` - Removes all borg items being ``NODROP`` https://github.com/user-attachments/assets/11442a10-3443-41f2-8c72-b38fb0126cdb Currently borgs are able to have their entire inventory open and a bag below it, which I thought was a little weird. I always assumed they WERE storage items, so I guess I'm doing it myself. Cyborgs using storage code makes it easier for contributors to actually do stuff with, without risking breaking everything. It also hopefully will make borg items more resilient against breaking in the future, now that we're not relying on nodrop. Also just brings them more in line with other mobs, all of which make use of storages. 🆑 refactor: Cyborg's modules now use storage (so opening a bag will close modules instead of overlap one over the other). qol: Observers can now see Cyborg's inventories (like they can for humans). /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
|
2bae025bfe |
Audits wash/cleaning signals + refactors wash() to ensure no needless mob updates occur (#91259)
## About The Pull Request This has the potential to create a lot of needless mob updates which is not great. Now should only update a mob's clothing if it was actually washed. This PR 1) ensures that all wash() procs return a bitflag. 2) ensures that `wash()` proccalls which result in expensive operations like icon updates only do so when it is necessary ## Why It's Good For The Game Updating mob sprites is expensive, and doing it when nothing has been changed is bad. ## Changelog Nothing really player facing |
||
|
|
c51ee7efa5 |
Cyborgs now use storage datum (#90927)
## About The Pull Request This moves Cyborgs onto using storage datums, removing the remenants of the shitcode that was Cyborg inventory. It's now done mostly by equipping/unequipping/storage items, much like how other mobs do. This allows borgs to take advantage of more hand support stuff and things like ``dropped()``, so borgs no longer have to copy paste drop code to ``cyborg_unequip`` It also: - Removes ``CYBORG_ITEM_TRAIT`` - Removes all borg items being ``NODROP`` https://github.com/user-attachments/assets/11442a10-3443-41f2-8c72-b38fb0126cdb ## Why It's Good For The Game Currently borgs are able to have their entire inventory open and a bag below it, which I thought was a little weird. I always assumed they WERE storage items, so I guess I'm doing it myself. Cyborgs using storage code makes it easier for contributors to actually do stuff with, without risking breaking everything. It also hopefully will make borg items more resilient against breaking in the future, now that we're not relying on nodrop. Also just brings them more in line with other mobs, all of which make use of storages. ## Changelog 🆑 refactor: Cyborg's modules now use storage (so opening a bag will close modules instead of overlap one over the other). qol: Observers can now see Cyborg's inventories (like they can for humans). /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
|
fb69fbb8a2 |
Refactor: Moves throwing and giving items from /mob/living/carbon to /mob/living (#91049)
Given the existence of basic mobs with hand slots, it feels like throwing and giving items shouldn't be something exclusive to carbon mobs, so I've pulled things around to make this happen. The only basic mobs with hands at time of writing are gorillas and dextrous holoparasites, but the inability to throw things when you're a gorilla just doesn't seem right to me. Some more details about what I've done here: - Made the dextrous component optionally enable throwing for the mob it's added to. - Moved offer/give item functionality to /mob/living (I can't see any reason why only carbon mobs should have this option) - Moved throwing and give item hotkeys from carbon to "human" (where all the other /mob/living hotkeys go) and, as a result, removed carbon hotkeys (nothing is left in them). - Moved throwing code and item offering code to its own file because living.dm is 3000+ lines long and should probably be broken up some day (I'm not brave enough for that) - Cleaned up an unused global signal that hasn't been used since dogs got moved to basic mobs. - Other miscellaneous cleanup where I noticed it. - In terms of testing: Tested using gorillas (only checked the dextrous holoparasite to confirm the button and hotkeys worked). Things that were working: - Can throw items if the mob is set up to allow it. - Can give items as a gorilla to a human, as a human to a gorilla, and as a human to a human. - Can give a high five to a gorilla (and the gorilla can receive it). Gorillas can't give a high five back, though (they don't have the emote), this already ballooned in scope, someone else can make that happen. - There are an alarmingly high amount of niche emote-into-item-into-giving behaviours I suspect half the playerbase or more aren't even aware of (does anyone offer their hand to someone to get them up off of the ground?) and I don't know if I broke any of them with this, but the fact high fives work gives me some hope they're probably still fine. Lets gorillas and dextrous holoparasites throw things and give things, but most importantly sets up more framework for any future dextrous basic mobs to also be able to do this. There's no real reason to keep this functionality confined to carbon mobs when dextrous basic mobs are a thing. 🆑 add: Gorillas can now throw things and offer items to players. refactor: Moved throwing and offering item code to be based on living mobs, not just carbon mobs. /🆑 --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
|
379e2a0ee0 |
Refactor: Moves throwing and giving items from /mob/living/carbon to /mob/living (#91049)
## About The Pull Request Given the existence of basic mobs with hand slots, it feels like throwing and giving items shouldn't be something exclusive to carbon mobs, so I've pulled things around to make this happen. The only basic mobs with hands at time of writing are gorillas and dextrous holoparasites, but the inability to throw things when you're a gorilla just doesn't seem right to me. Some more details about what I've done here: - Made the dextrous component optionally enable throwing for the mob it's added to. - Moved offer/give item functionality to /mob/living (I can't see any reason why only carbon mobs should have this option) - Moved throwing and give item hotkeys from carbon to "human" (where all the other /mob/living hotkeys go) and, as a result, removed carbon hotkeys (nothing is left in them). - Moved throwing code and item offering code to its own file because living.dm is 3000+ lines long and should probably be broken up some day (I'm not brave enough for that) - Cleaned up an unused global signal that hasn't been used since dogs got moved to basic mobs. - Other miscellaneous cleanup where I noticed it. - In terms of testing: Tested using gorillas (only checked the dextrous holoparasite to confirm the button and hotkeys worked). Things that were working: - Can throw items if the mob is set up to allow it. - Can give items as a gorilla to a human, as a human to a gorilla, and as a human to a human. - Can give a high five to a gorilla (and the gorilla can receive it). Gorillas can't give a high five back, though (they don't have the emote), this already ballooned in scope, someone else can make that happen. - There are an alarmingly high amount of niche emote-into-item-into-giving behaviours I suspect half the playerbase or more aren't even aware of (does anyone offer their hand to someone to get them up off of the ground?) and I don't know if I broke any of them with this, but the fact high fives work gives me some hope they're probably still fine. ## Why It's Good For The Game Lets gorillas and dextrous holoparasites throw things and give things, but most importantly sets up more framework for any future dextrous basic mobs to also be able to do this. There's no real reason to keep this functionality confined to carbon mobs when dextrous basic mobs are a thing. ## Changelog 🆑 add: Gorillas can now throw things and offer items to players. refactor: Moved throwing and offering item code to be based on living mobs, not just carbon mobs. /🆑 --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
|
0f01987115 |
Refactors ITEM_SLOT_BACKPACK and ITEM_SLOT_BELTPACK out of inventory code (#90869)
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may not be viewable. --> <!-- You can view Contributing.MD for a detailed description of the pull request process. --> ## About The Pull Request So yesterday I've spotted that we had wrong SLOTS_AMT value set, and went a bit down a rabbit hole and found how abhorrent our ITEM_SLOT_BACKPACK and ITEM_SLOT_BELTPACK usage is. They're not real inventory slots, but just "hints" at items being located in backpacks or belts, or instructions to put an item into a belt/backpack. This PR rewrites all usages of them as "hints", and adds an equip_to_storage proc used to equip an item into a storage positioned in a certain slot, so ``equip_to_slot_if_possible(item, ITEM_SLOT_BACKPACK)`` is now ``equip_to_storage(item, ITEM_SLOT_BACK)`` ## Why It's Good For The Game Its really stupid and we shouldn't have those as slot flags, ITEM_SLOT_HANDS at least makes sense but those two are just absurd. Should make equipping things into non-backpack storage a bit easier too, in case we end up going through with the idea of suit/uniform pockets being a major part of player inventory. ## Changelog <!-- If your PR modifies aspects of the game that can be concretely observed by players or admins you should add a changelog. If your change does NOT meet this description, remove this section. Be sure to properly mark your PRs to prevent unnecessary GBP loss. You can read up on GBP and its effects on PRs in the tgstation guides for contributors. Please note that maintainers freely reserve the right to remove and add tags should they deem it appropriate. You can attempt to finagle the system all you want, but it's best to shoot for clear communication right off the bat. --> 🆑 refactor: Refactored how backpack and belt contents are handled in mob inventory code, report any issues with lingering item effects or inability to equip things into them! /🆑 <!-- Both 🆑's are required for the changelog to work! You can put your name to the right of the first 🆑 if you want to overwrite your GitHub username as author ingame. --> <!-- You can use multiple of the same prefix (they're only used for the icon ingame) and delete the unneeded ones. Despite some of the tags, changelogs should generally represent how a player might be affected by the changes rather than a summary of the PR's contents. --> |
||
|
|
352c7ecdd7 |
Refactors ITEM_SLOT_BACKPACK and ITEM_SLOT_BELTPACK out of inventory code (#90869)
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may not be viewable. --> <!-- You can view Contributing.MD for a detailed description of the pull request process. --> ## About The Pull Request So yesterday I've spotted that we had wrong SLOTS_AMT value set, and went a bit down a rabbit hole and found how abhorrent our ITEM_SLOT_BACKPACK and ITEM_SLOT_BELTPACK usage is. They're not real inventory slots, but just "hints" at items being located in backpacks or belts, or instructions to put an item into a belt/backpack. This PR rewrites all usages of them as "hints", and adds an equip_to_storage proc used to equip an item into a storage positioned in a certain slot, so ``equip_to_slot_if_possible(item, ITEM_SLOT_BACKPACK)`` is now ``equip_to_storage(item, ITEM_SLOT_BACK)`` ## Why It's Good For The Game Its really stupid and we shouldn't have those as slot flags, ITEM_SLOT_HANDS at least makes sense but those two are just absurd. Should make equipping things into non-backpack storage a bit easier too, in case we end up going through with the idea of suit/uniform pockets being a major part of player inventory. ## Changelog <!-- If your PR modifies aspects of the game that can be concretely observed by players or admins you should add a changelog. If your change does NOT meet this description, remove this section. Be sure to properly mark your PRs to prevent unnecessary GBP loss. You can read up on GBP and its effects on PRs in the tgstation guides for contributors. Please note that maintainers freely reserve the right to remove and add tags should they deem it appropriate. You can attempt to finagle the system all you want, but it's best to shoot for clear communication right off the bat. --> 🆑 refactor: Refactored how backpack and belt contents are handled in mob inventory code, report any issues with lingering item effects or inability to equip things into them! /🆑 <!-- Both 🆑's are required for the changelog to work! You can put your name to the right of the first 🆑 if you want to overwrite your GitHub username as author ingame. --> <!-- You can use multiple of the same prefix (they're only used for the icon ingame) and delete the unneeded ones. Despite some of the tags, changelogs should generally represent how a player might be affected by the changes rather than a summary of the PR's contents. --> |
||
|
|
77bbcfd764 |
Merges crusher retool kits into one, datumizes crusher skins, gives dagger and blaster unique animations (#90742)
## About The Pull Request Merges sword, harpoon, glaive and dagger crusher retools into a single item which allows you to pick the skin you want upon being applied to a crusher by converting crusher skins into datums. I've also improved sprites for all skins and redid the retool kit itself, as well as gave dagger and blaster unique animations - you swing with a dagger for normal attacks, stab to rupture the mark, and firing a shot point-blank does a stabbing animation with the blaster.  https://github.com/user-attachments/assets/2d243daf-f1d8-48bf-a661-8a9ac990837c (Apologies for lack of robust gameplay, I was trying to show the animations, not kill the goliath) The harpoon crusher skin now does stabbing animation instead of slashing one, and I've also fixed animations playing incorrectly when attacking large mobs/objects ## Why It's Good For The Game Having multiple items for reskinning crushers feels clunky, and unique animations are just something that makes sense. Having a swinging animation for both dagger and blaster looked odd, as you'd probably only swing one of them at the opponent, so I decided to spice them up. ## Changelog 🆑 add: Dagger-blaster and harpoon crusher skins have received unique attack animations. add: Four base crusher retool kits have been merged into one item. image: Resprited crusher skins and the crusher retool kit fix: Fixed attack animations being offset when attacking large objects or mobs. /🆑 |
||
|
|
6e17e9b62b |
Removes 'thrownby' var on items (#90877)
## About The Pull Request Fully removes thrownby as a var on items, and is now instead handled by throwingdatums' ``get_thrower()`` proc Also replaces the early return for throwing things at yourself (it now only prevents the call for check_block and therefore hit reaction stuff), since the only way to throw things at yourself is with boomerangs, which currently only works because it doesn't pass you as the thrower for boomerang's return Speaking of, boomerangs now see the thrower as thrower on returns Before (Boomerangs don't pass you as the thrower, so it shows you as being hit by nothing):  After (Boomerangs pass you and you can affect yourself, so it sees you hitting yourself & it still batons you):  This is gonna be used for https://github.com/tgstation/tgstation/pull/90689 as well. ## Why It's Good For The Game Better logging for boomeranged items, removes a deprecated var and better consistency for thrown items leaving better readability. ## Changelog 🆑 admin: People throwing boomeranged items and hitting themselves now logs it as them hitting themselves (rather than being hit by the air). /🆑 |
||
|
|
b0aaeca5ae |
Merges crusher retool kits into one, datumizes crusher skins, gives dagger and blaster unique animations (#90742)
## About The Pull Request Merges sword, harpoon, glaive and dagger crusher retools into a single item which allows you to pick the skin you want upon being applied to a crusher by converting crusher skins into datums. I've also improved sprites for all skins and redid the retool kit itself, as well as gave dagger and blaster unique animations - you swing with a dagger for normal attacks, stab to rupture the mark, and firing a shot point-blank does a stabbing animation with the blaster.  https://github.com/user-attachments/assets/2d243daf-f1d8-48bf-a661-8a9ac990837c (Apologies for lack of robust gameplay, I was trying to show the animations, not kill the goliath) The harpoon crusher skin now does stabbing animation instead of slashing one, and I've also fixed animations playing incorrectly when attacking large mobs/objects ## Why It's Good For The Game Having multiple items for reskinning crushers feels clunky, and unique animations are just something that makes sense. Having a swinging animation for both dagger and blaster looked odd, as you'd probably only swing one of them at the opponent, so I decided to spice them up. ## Changelog 🆑 add: Dagger-blaster and harpoon crusher skins have received unique attack animations. add: Four base crusher retool kits have been merged into one item. image: Resprited crusher skins and the crusher retool kit fix: Fixed attack animations being offset when attacking large objects or mobs. /🆑 |
||
|
|
853c9196b6 |
Removes 'thrownby' var on items (#90877)
## About The Pull Request Fully removes thrownby as a var on items, and is now instead handled by throwingdatums' ``get_thrower()`` proc Also replaces the early return for throwing things at yourself (it now only prevents the call for check_block and therefore hit reaction stuff), since the only way to throw things at yourself is with boomerangs, which currently only works because it doesn't pass you as the thrower for boomerang's return Speaking of, boomerangs now see the thrower as thrower on returns Before (Boomerangs don't pass you as the thrower, so it shows you as being hit by nothing):  After (Boomerangs pass you and you can affect yourself, so it sees you hitting yourself & it still batons you):  This is gonna be used for https://github.com/tgstation/tgstation/pull/90689 as well. ## Why It's Good For The Game Better logging for boomeranged items, removes a deprecated var and better consistency for thrown items leaving better readability. ## Changelog 🆑 admin: People throwing boomeranged items and hitting themselves now logs it as them hitting themselves (rather than being hit by the air). /🆑 |
||
|
|
76922f74ff |
Fixes items in storages sometimes lingering in observer UI (#90870)
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may not be viewable. --> <!-- You can view Contributing.MD for a detailed description of the pull request process. --> ## About The Pull Request doMove on item didn't account for observers, and while doUnEquip should not be an issue, I've added the same observer image removal code as a safeguard to it regardless. ## Changelog <!-- If your PR modifies aspects of the game that can be concretely observed by players or admins you should add a changelog. If your change does NOT meet this description, remove this section. Be sure to properly mark your PRs to prevent unnecessary GBP loss. You can read up on GBP and its effects on PRs in the tgstation guides for contributors. Please note that maintainers freely reserve the right to remove and add tags should they deem it appropriate. You can attempt to finagle the system all you want, but it's best to shoot for clear communication right off the bat. --> 🆑 fix: Fixed items in storages sometimes lingering in observer UI /🆑 <!-- Both 🆑's are required for the changelog to work! You can put your name to the right of the first 🆑 if you want to overwrite your GitHub username as author ingame. --> <!-- You can use multiple of the same prefix (they're only used for the icon ingame) and delete the unneeded ones. Despite some of the tags, changelogs should generally represent how a player might be affected by the changes rather than a summary of the PR's contents. --> |
||
|
|
075d966320 |
Added additional layers to hairstyles (#90275)
## About The Pull Request Added two new "layers" to hairstyles. The first draws on the normal hair layer but resists being affected by hair masks unless a piece of clothing really insists that it must mask it. The second draws on top of the headwear layer and will ignore all hair masking, but will disappear entirely if a piece of clothing covers the part of the head that hairpiece originates from. Each of these "Layers" (called "hair appendages" in the code) is associated with a part of the head that it comes off of (left side, rear, right side, etc.), which pieces of clothing can cover to prevent those parts from being shown. For example, a Beret will allow a ponytail to sprout off the back of a person's head and ignore the normal hair mask, but a winter coat hood covers every part of the head except the front, so it will hide the ponytail completely. ## Costs Hairstyles that use this system require some extra icon blending, but each hairstyle will cache the result of each blend whenever a new hair mask is applied, so the extra cost only happens once. The cache will also be used on hairstyles that don't utilize the additional layers, so we should end up with less total icon blending over the course of a round than we currently have. Adds a new sprite layer, OUTER_HAIR_LAYER, to humans. Changes hair masks from strings specifying an icon state to datums with an icon state and a bitfield storing which parts of the head the headware that uses them cover. The singletons for these datums are stored in the SSaccessories subsystem. Any hairstyle that uses this system will need 1-2 more icon states in the human_face.dmi file. I currently have 32 hairstyles marked that could reasonably use this system, about half of which use both additional icon states. ## Images Old system:  New system:   The new system is currently only implemented on the "Ponytail (High)" hairstyle for demonstration and testing. I have a branch with the same update for most similar hairstyles I can push if this is merged. ## Why It's Good For The Game Hair masks are okay but they look really bad with some hairstyles. This allows people who really care about their character's look to make their hairstyles work with their favorite hats. Potential for fixing #88886 ## Changelog 🆑 add: Added a system to create hairstyles with multiple layers to allow better interaction with hats and helmets image: Added additional sprite layers to the Ponytail (High) hairstyle /🆑 --------- Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> |
||
|
|
ea6654b3c2 | Fix edge-cases where clothing icons wouldn't update when equipped (#90396) | ||
|
|
59c249d9c6 |
Fixes items in storages sometimes lingering in observer UI (#90870)
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may not be viewable. --> <!-- You can view Contributing.MD for a detailed description of the pull request process. --> ## About The Pull Request doMove on item didn't account for observers, and while doUnEquip should not be an issue, I've added the same observer image removal code as a safeguard to it regardless. ## Changelog <!-- If your PR modifies aspects of the game that can be concretely observed by players or admins you should add a changelog. If your change does NOT meet this description, remove this section. Be sure to properly mark your PRs to prevent unnecessary GBP loss. You can read up on GBP and its effects on PRs in the tgstation guides for contributors. Please note that maintainers freely reserve the right to remove and add tags should they deem it appropriate. You can attempt to finagle the system all you want, but it's best to shoot for clear communication right off the bat. --> 🆑 fix: Fixed items in storages sometimes lingering in observer UI /🆑 <!-- Both 🆑's are required for the changelog to work! You can put your name to the right of the first 🆑 if you want to overwrite your GitHub username as author ingame. --> <!-- You can use multiple of the same prefix (they're only used for the icon ingame) and delete the unneeded ones. Despite some of the tags, changelogs should generally represent how a player might be affected by the changes rather than a summary of the PR's contents. --> |
||
|
|
753d8e5ba4 | Merge branch 'master' of https://github.com/tgstation/tgstation into upstream-25-04a | ||
|
|
6a9ee3b1c6 |
Added additional layers to hairstyles (#90275)
## About The Pull Request Added two new "layers" to hairstyles. The first draws on the normal hair layer but resists being affected by hair masks unless a piece of clothing really insists that it must mask it. The second draws on top of the headwear layer and will ignore all hair masking, but will disappear entirely if a piece of clothing covers the part of the head that hairpiece originates from. Each of these "Layers" (called "hair appendages" in the code) is associated with a part of the head that it comes off of (left side, rear, right side, etc.), which pieces of clothing can cover to prevent those parts from being shown. For example, a Beret will allow a ponytail to sprout off the back of a person's head and ignore the normal hair mask, but a winter coat hood covers every part of the head except the front, so it will hide the ponytail completely. ## Costs Hairstyles that use this system require some extra icon blending, but each hairstyle will cache the result of each blend whenever a new hair mask is applied, so the extra cost only happens once. The cache will also be used on hairstyles that don't utilize the additional layers, so we should end up with less total icon blending over the course of a round than we currently have. Adds a new sprite layer, OUTER_HAIR_LAYER, to humans. Changes hair masks from strings specifying an icon state to datums with an icon state and a bitfield storing which parts of the head the headware that uses them cover. The singletons for these datums are stored in the SSaccessories subsystem. Any hairstyle that uses this system will need 1-2 more icon states in the human_face.dmi file. I currently have 32 hairstyles marked that could reasonably use this system, about half of which use both additional icon states. ## Images Old system:  New system:   The new system is currently only implemented on the "Ponytail (High)" hairstyle for demonstration and testing. I have a branch with the same update for most similar hairstyles I can push if this is merged. ## Why It's Good For The Game Hair masks are okay but they look really bad with some hairstyles. This allows people who really care about their character's look to make their hairstyles work with their favorite hats. Potential for fixing #88886 ## Changelog 🆑 add: Added a system to create hairstyles with multiple layers to allow better interaction with hats and helmets image: Added additional sprite layers to the Ponytail (High) hairstyle /🆑 --------- Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> |
||
|
|
02af2fdba8 | Fix edge-cases where clothing icons wouldn't update when equipped (#90396) | ||
|
|
abb8f539bd |
Cain & Abel (new mining loot) (#89455)
## About The Pull Request adds the Cain & Abel to the lootpool of the colossus!  these are a set of angelic twinblades bound together by some chains. The long chains allow u to attack mobs from a distance (2 tiles max) and at very FAST speed, and come with a few new mechanics: -Attacking a mob with the cain and abel grants you a special whisp that follows your character. these whisps empower ur next melee attacks u can collect a maximum of up to 6 whisps, (their bonuses stack), after which they reset. If u get hit by a mob once, you'll lose ur whisps (and ur melee bonus), so ull have to regain them by rebuilding up ur combo. u can also choose to sacrifice ur whisps by firing them at mobs (by right clicking them) for some hefty damage (this again means u'll lose them) https://github.com/user-attachments/assets/0a1738db-9fa4-4226-ac80-334f5e97cfa5 -u can also choose to hurl one of ur daggers at enemies, there's 2 throw modes u can toggle between by pressing Z while holding ur weapon. 1- On launch mode, u can throw one of ur daggers at a tile, afterwhich the chains will rapidly pull u towards it, making for some cool getaways in tense situations. this puts throw mode on a 7 second cooldown 2- On crystal mode, u can hurl a dagger at an enemy or at a tile. Spiked crystals will errupt on nearby floors, dealing some damage to nearby mobs and stunning them for 2 seconds (bosses dont get stunned tho). puts throw mode on a 15 second cooldown https://github.com/user-attachments/assets/665b9cf4-c5a1-4263-a36b-86e3f35d0ae5 -Lastly is the swing ability. This will swing ur daggers around u, dealing AOE damage to nearby mobs, and makes u block all melee attacks, tentacle attacks, and deflect incoming projectile attacks (could for example be used to deflect the colossus' shotgun blast back to it). ull only block attacks while the animation is active, which lasts a good 1.75 seconds, and is at a 20 second cooldown. https://github.com/user-attachments/assets/073e5324-af5b-45ab-912e-5bcaa13fc728 Here's a short clip of me using them to fight a colossus and a bubblegum https://www.youtube.com/watch?v=kp5Hu16dHPQ&ab_channel=Kobsa ## Why It's Good For The Game adds a new fun weapon with a few deep mechanics to the game. also makes taking down colossi alot more rewarding. ## Changelog 🆑 add: adds the cain and abel to the colossus lootpool! /🆑 # Conflicts: # icons/mob/inhands/equipment/kitchen_lefthand.dmi |
||
|
|
7c81098d33 |
Cain & Abel (new mining loot) (#89455)
## About The Pull Request adds the Cain & Abel to the lootpool of the colossus!  these are a set of angelic twinblades bound together by some chains. The long chains allow u to attack mobs from a distance (2 tiles max) and at very FAST speed, and come with a few new mechanics: -Attacking a mob with the cain and abel grants you a special whisp that follows your character. these whisps empower ur next melee attacks u can collect a maximum of up to 6 whisps, (their bonuses stack), after which they reset. If u get hit by a mob once, you'll lose ur whisps (and ur melee bonus), so ull have to regain them by rebuilding up ur combo. u can also choose to sacrifice ur whisps by firing them at mobs (by right clicking them) for some hefty damage (this again means u'll lose them) https://github.com/user-attachments/assets/0a1738db-9fa4-4226-ac80-334f5e97cfa5 -u can also choose to hurl one of ur daggers at enemies, there's 2 throw modes u can toggle between by pressing Z while holding ur weapon. 1- On launch mode, u can throw one of ur daggers at a tile, afterwhich the chains will rapidly pull u towards it, making for some cool getaways in tense situations. this puts throw mode on a 7 second cooldown 2- On crystal mode, u can hurl a dagger at an enemy or at a tile. Spiked crystals will errupt on nearby floors, dealing some damage to nearby mobs and stunning them for 2 seconds (bosses dont get stunned tho). puts throw mode on a 15 second cooldown https://github.com/user-attachments/assets/665b9cf4-c5a1-4263-a36b-86e3f35d0ae5 -Lastly is the swing ability. This will swing ur daggers around u, dealing AOE damage to nearby mobs, and makes u block all melee attacks, tentacle attacks, and deflect incoming projectile attacks (could for example be used to deflect the colossus' shotgun blast back to it). ull only block attacks while the animation is active, which lasts a good 1.75 seconds, and is at a 20 second cooldown. https://github.com/user-attachments/assets/073e5324-af5b-45ab-912e-5bcaa13fc728 Here's a short clip of me using them to fight a colossus and a bubblegum https://www.youtube.com/watch?v=kp5Hu16dHPQ&ab_channel=Kobsa ## Why It's Good For The Game adds a new fun weapon with a few deep mechanics to the game. also makes taking down colossi alot more rewarding. ## Changelog 🆑 add: adds the cain and abel to the colossus lootpool! /🆑 |
||
|
|
6e3307e01f |
Fixes incorrect offsets on wide items' attack animations (#90187)
## About The Pull Request Looks jank if you hit something with like, a Sakhno, not sure what else to add. ## Changelog 🆑 fix: Fixed incorrect offsets on wide items' attack animations /🆑 |
||
|
|
eb2796831b |
[MDB Ignore] Refactors pills, patches, and generalizes stomach contents, nothing to see here. (#89549)
## About The Pull Request Currently patches are a subtype of pills, and while they have the ``dissolveable`` var set to FALSE, barely anything checks it (because people don't expect patches to be pills in disguise) so we end up patches being dissolveable and implantable, which is far from ideal. Both have been moved into an ``/obj/item/reagent_containers/applicator`` class, which handles their common logic and helps handling cases where either one fits. As for gameplay changes: * Pills no longer dissolve instantly, instead adding their contents to your stomach after 3 seconds (by default). You can increase the timer by dropping sugar onto them to thicken their coating, 1s per 1u applied, up to a full minute. Coating can also be dissolved with water, similarly -1s per 1u applied. Pills with no coating will work like before. * Patches now only take half as long to apply (1.5s), but also slowly trickle in their reagents instead of instantly applying all of them. This is done via embedding so you could theoretically (if you get lucky) stick a ranged patch at someone, although they are rather quick to rip off. The implementation and idea itself are separate, but the idea for having a visual display has been taken from https://github.com/Monkestation/Monkestation2.0/pull/2558.  * In order to support the new pill mechanics, stomachs have received contents. Pills and items that you accidentally swallow now go into your stomach instead of your chest cavity, and may damage it if they're sharp, requiring having them surgically cut out (cut the stomach open with a scalpel, then cauterize it to mend the incision). Or maybe you can get a bacchus's blessing, or a geneticist hulk to gut punch you, that may also work. Alien devour ability also uses this system now. If you get a critical slashing wound on your chest contents of your cut apart stomach (if a surgeon forgot to mend it, or if you ate too much glass shard for breakfast) may fall out. However, spacemen with the strong stomach trait can eat as much glass cereal as they want. Pill duration can also be chosen in ChemMaster when you have a pill selected, 0 to 30 seconds.  ## Why It's Good For The Game Patches and pills are extremely similar in their implemenation, former being a worse version of sprays and pills, with only change being that pills cannot be applied through helmets while patches and sprays ignore both. This change makes them useful for separate cases, and allows reenactment of some classic... movie, scenes, with the pill change. As for stomach contents, this was probably the sanest way of implementing pill handling, and everything else (item swallowing and cutting stomachs open to remove a cyanide pill someone ate before it dissolves) kind of snowballed from there. I pray to whatever gods that are out there that this won't have some extremely absurd and cursed interactions (it probably will). ## Changelog 🆑 add: Instead of dissolving instantly, pills now activate after 4 seconds. This timer can be increased by using a dropper filled with sugar on them, 1s added per 1u dropped. add: Patches now stick to you and slowly bleed their reagents, instead of being strictly inferior to both pills and sprays. add: Items that you accidentally swallow now go into your stomach contents. refactor: Patches are no longer considered pills by the game refactor: All stomachs now have contents, instead of it being exclusive to aliens. You can cut open a stomach to empty it with a scalpel, and mend an existing incision with a cautery. /🆑 |
||
|
|
d72d51f0d5 |
Make too low vols and no soundin scream for playsound instead of failing silently (#89746)
…ing silently ## About The Pull Request While reviewing the recent sound optimization PR I noticed that a bunch of checks here really make no sense to just fail silently when nobody should be doing this in the first place Immediately started screaming on run so thats a good sign ## Changelog 🆑 code: previously silent failures due to empty sounds or too low volumes will now create a runtime in the runtime log fix: some footstep sounds like robotic or slimes are no longer silent /🆑 --------- Co-authored-by: TiviPlus <572233640+TiviPlus@users.noreply.com> |