8 Commits

Author	SHA1	Message	Date
necromanceranne	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>	2025-06-19 17:49:59 +02:00
Ghom	339616ae78	You can now interact with held mobs beside wearing them (feat: "minor" melee attack chain cleanup) (#90080) ... ## About The Pull Request People can now pet held mothroaches and pugs if they want to, or use items on them, hopefully without causing many issues. After all, it only took about a couple dozen lines of code to make... ...Oh, did the 527 files changed or the 850~ lines added/removed perhaps catch your eye? Made you wonder if I accidentally pushed the wrong branch? or skewed something up big time? Well, nuh uh. I just happen to be fed up with the melee attack chain still using stringized params instead of an array/list. It was frankly revolting to see how I'd have had to otherwise call `list2params` for what I'm trying to accomplish here, and make this PR another tessera to the immense stupidity of our attack chain procs calling `params2list` over and over and over instead of just using that one call instance from `ClickOn` as an argument. It's 2025, honey, wake up! I also tried to replace some of those single letter vars/args but there are just way too many of them. ## Why It's Good For The Game Improving old code. And I want to be able to pet mobroaches while holding them too. ## Changelog 🆑 qol: You can now interact with held mobs in more ways beside wearing them. /🆑	2025-04-23 20:18:26 +00:00
SmArtKar	7f15e11993	Adds a new syringe gun mode and improves foam darts. (#89510) ... ## About The Pull Request This PR implements multiple new features: Foam darts now can stick to people as long as their cap isn't removed. Riot foam darts have a chance to jostle when you move with one stuck inside of you, dealing a bit of stamina damage from the weight stuck to your limbs. Syringe guns received a second "low power" mode, toggleable with in-hand right click. In this mode, syringes fired will embed into their target and slowly leak their reagents instead of instantly delivering them. Thankfully, they can be plucked out pretty quickly. You can also insert syringes into uncapped (screwdriver-ed) foam darts (similarly to pens) to achieve the same result, allowing you to get a bootleg low-efficiency syringe gun. Additionally, I fixed/cleaned up some embedding issues/code which I found while coding this. ## Why It's Good For The Game This allows players to explore new funny interactions between items and chems, as we don't have a reliable slow release mechanism aside from IV drips currently. And foam darts embedding it just (mostly) harmless fluff, if someone figures out a way to cause havoc with it then I'll be very proud of them (someone totally will). ## Changelog 🆑 add: Foam darts now stick to people when they have their cap on, riot foam darts also can passively deal a bit of stamina damage when you move with one. add: Syringes can be inserted into foam darts, making them embed and slowly leak their reagents into their victim. add: Syringe guns can be toggled (with right click) between high power and low power modes, former being their normal functionality and latter making syringes embed and slowly leak their contents. fix: Fixed projectiles sometimes not embedding when they should've code: Cleaned embedding code up /🆑	2025-03-01 22:52:19 +11:00
SmArtKar	3499727a6d	Implements datumized embedding handlers in place of element-component-datum triad (#88511) ... ## About The Pull Request This PR completely rewrites our embedding system in favor of embedding datum handlers which acts as containers for all embedding-related data and logic. Currently embedding logic relies on an element-component-datum triad, where elements on the items handle embedding logic, singleton datums store embedding data and components (which get assigned to ***mobs*** in whom the item embedded) handle pain and the item being ripped out. How do we access all the procs? By using comsigs as procs, which is really bad. This code was written back in 2020 when DCS was hot stuff but in hindsight this implementation was a mistake, as it heavily restricts custom embedding behaviors unless you're willing to constantly run GetComponent (bad, ugly, incarnation of evil) This PR rewrites all that logic to be handled by lazyloaded ``/datum/embedding``, which is stored similarly to current ``/datum/embed_data``. Upon being requested, it is initialized and assigned to a parent from whom all the logic is handled, from being embedded to pain and having the item ripped out. On projectiles this only handles one proc, after which it copies itself down to the shrapnel item instead and runs the chain further from there. Ideally, most embedding-related logic now should be handled purely datum-side - in most cases items should not be hooking up to themselves like they did before (unless said logic is for when the item is made sticky or smth) and instead the code should be handled by the embedding datum (see sholean grapes implementation in this PR). This should allow us to do fancy stuff like syringe guns embedding syringes into targets and injecting them that way, and fix some bugs along the way. Closes #88115 Closes #87946 Also fixed a bug with scars not displaying when examined closely from #86506 because i was in the area anyways	2025-01-02 23:18:27 +00:00
SmArtKar	bbb7a41743	Guncode Agony 4: The Great Projectile Purge (#87740) ... ## About The Pull Request ~~Kept you waitin huh!~~ The projectile refactor is finally here, 4 years later. This PR (almost) completely rewrites projectile logic to be more maintainable and performant. ### Key changes: * Instead of moving by a fixed amount of pixels, potentially skipping tile corners and being performance-heavy, projectiles now use raymarching in order to teleport through tiles and only visually animate themselves. This allows us to do custom per-projectile animations and makes the code much more reliable, sane and maintainable. You (did not) serve us well, pixel_move. * Speed variable now measures how many tiles (if SSprojectiles has default values) a projectile passes in a tick instead of being a magical Kevinz Unit™️ coefficient. pixel_speed_multiplier has been retired because it never had a right to exist in the first place. __This means that downstreams will need to set all of their custom projectiles' speed values to ``pixel_speed_multiplier / speed``__ in order to prevent projectiles from inverting their speed. * Hitscans no longer operate with spartial vectors and instead only store key points in which the projectile impacted something or changed its angle. This should similarly make the code much easier to work with, as well as fixing some visual jank due to incorrect calculations. * Projectiles only delete themselves the ***next*** tick after impacting something or reaching their maximum range. Doing so allows them to finish their impact animation and hide themselves between ticks via animation chains. This means that projectiles no longer disappear ~a tile before hitting their target, and that we can finally make impact markers be consistent with where the projectile actually landed instead of being entirely random. <details> <summary>Here is an example of how this affects our slowest-moving projectile: Magic Missiles.</summary> Before: https://github.com/user-attachments/assets/06b3a980-4701-4aeb-aa3e-e21cd056020e After: https://github.com/user-attachments/assets/abe8ed5c-4b81-4120-8d2f-cf16ff5be915 </details> <details> <summary>And here is a much faster, and currently jankier, disabler SMG.</summary> Before: https://github.com/user-attachments/assets/2d84aef1-0c83-44ef-a698-8ec716587348 After: https://github.com/user-attachments/assets/2e7c1336-f611-404f-b3ff-87433398d238 </details> ### But how will this affect the ~~trout population~~ gameplay? Beyond improved visuals, smoother movement and a few minor bugfixes, this should not have a major gameplay impact. If something changed its behavior in an unexpected way or started looking odd, please make an issue report. Projectile impacts should now be consistent with their visual position, so hitting and dodging shots should be slightly easier and more intuitive. This PR should be testmerged extensively due to the amount of changes it brings and considerable difficulty in reviewing them. Please contact me to ensure its good to merge. Closes #71822 Closes #78547 Closes #78871 Closes #83901 Closes #87802 Closes #88073 ## Why It's Good For The Game Our core projectile code is an ungodly abomination that nobody except me, Kapu and Potato dared to poke in the past months (potentially longer). It is laggy, overcomplicated and absolutely unmaintaineable - while a lot of decisions made sense 4 years ago when we were attempting to introduce pixel movement, nowadays they are only acting as major roadblocks for any contributor who is attempting to make projectile behavior that differs from normal in any way. Huge thanks to Kapu and Potato (Lemon) on the discord for providing insights, ideas and advice throughout the past months regarding potential improvements to projectile code, almost all of which made it in. ## Changelog 🆑 qol: Projectiles now visually impact their targets instead of disappearing about a tile short of it. fix: Fixed multiple minor issues with projectile behavior refactor: Completely rewrote almost all of our projectile code - if anything broke or started looking/behaving oddly, make an issue report! /🆑	2024-11-23 04:02:35 -08:00
SmArtKar	b6c84135c3	Refactors embedding to use datums instead of storing data in bespoke elements (#84599) ... ## About The Pull Request This refactors embedding elements to make them use singleton datums (similarly to armor) instead being bespoke and creating a new element every time armor values are supposed to be adjusted. Default values have been removed from defines due to now being declared in base class itself. Additionally fixes vending machines and tackling gloves setting generated shards (which they instantly embed into their victim) embed properties to null after running the embedding code, despite said shards having non-null embedding values by default, making them not be able to embed into anyone else, also potentially breaking the pain/jostling code if they somehow get updated. ## Why It's Good For The Game Current embedding system is an unnecessarily complicated mess as bespoke elements are hard to work with, and creating a new element every time you change values is hacky at best. This change should make it easier to read and work with. ## Changelog 🆑 fix: Fixed glass shards generated from falling vending machines or tackling windows not being able to embed into anyone. refactor: Refactored embedding code to use datums instead of bespoke elements and ugly associated lists. /🆑	2024-07-07 23:20:07 +02:00
Y0SH1M4S73R	c670e5d921	[NO GBP] Makes dart insert projectile var modification code slightly better (#79886) ... ## About The Pull Request Ninja told me that I shouldn't use a signal to get the variable modifiers that a dart insert applies to its projectile. When I asked if using a callback passed as an initialization param was okay, Potato told me it was better. ## Why It's Good For The Game Less code smells. ## Changelog No player-facing changes.	2023-11-23 18:01:34 +01:00
Y0SH1M4S73R	376781879c	Different pen types have unique behavior when used in foam darts. (#79587) ... ## About The Pull Request This PR makes the following changes: - Refactors inserting items into foam darts into a component on items that can be inserted into darts - Adds the aforementioned component to pens - Provides an inspection tip for how to modify a foam dart - Gives different pen types specific behavior when used in a foam dart Pens typically give a foam dart 5 brute and 50% embed chance (affected by falloff). The following types of pens give the specified properties (usually directly derived from the pen's stats and additional functions): - Red pen (and four-color pen set to red): Slightly faster dart - Captain's fountain pen: Slightly faster dart, and 75% base embed chance - Sleepypen: Tries to inject its reagents into the hit mob, but doesn't penetrate thick clothing like syringe guns do - Energy Dagger: 35 brute, 100% base embed chance, and slightly faster dart - Survival Pen: Mines rocks on impact - Fine Tip Pen (if someone somehow manages to get one): 100 bare wound bonus and 9000 demolition modifier ## Why It's Good For The Game Expands the emergent gameplay possibilities of using pens in foam darts. While there are balance risks involved with traitors being able to buy the equivalent of reusable 45u syringe shots and 35 brute bullets, you are not likely to get your pen back once it hits its target, unless you somehow have the recall spell and have bound the pen to it. There are probably more TC-efficient ways to achieve comparable projectile weaponry, but foam dart guns have an air of subtlety to them... at least until your skin is pierced by a pointy writing implement that may also be something more deadly. If maintainers still have balance concerns, please let me know. ## Changelog 🆑 add: Certain types of pens now function like you expect they would when inserted into a foam dart qol: Examining a foam dart closely will show you how to modify it, or what it is modified with /🆑	2023-11-21 20:34:41 -05:00