## 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
/🆑
## 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#88115Closes#87946
Also fixed a bug with scars not displaying when examined closely from
#86506 because i was in the area anyways
## 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.
/🆑
## 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
/🆑
## About The Pull Request
So, when I made the `caseless` and `projectile_drop` elements, I failed
to take into account that bullets have an embedding variable sets, which
led to a few projectiles being embeddable when they shouldn't.
Beyond that, I wanted arrows and harpoons to be reusable yet embeddable,
which lead me to change a couple lines on the `embed` element, since
whoever made the element thought it was a good idea to add the
unnecessary step of attaching a copy of it to the `payload_type` of a
fired projectile before trying to embed it. Like, why? All that's going
to do is cause the resulting item to become embeddable, which may be an
issue for anything other than drop-deletable shrapnels. So yea, arrows
and harpoons, and emagged lollipops will now embed properly.
I've also deleted an unused, problematic subtype of quiver and arrow
casing, and made the quiver storage use
## Why It's Good For The Game
This will fix#77187. Perhaps buff harpoons and arrows a little but meh.
## Changelog
🆑
fix: Fixed fired foam darts, gumballs and (harmless) lollipops being
embeddable.
fix: Projectiles that should embed while being reusable will now do so
correctly, actually embedding the reusable casing instead of a shrapnel.
balance: Arrows are generally more likely to embed now, except for
blazing ones, that kind of just blaze.
qol: the quiver storage now uses numerical stacking (like botany and ore
bags, or the RPED, for example).
/🆑
The reusable and caseless types only purposes are the behaviors of
deleting the casing when fired and spawning a new object when the
projectile ultimately reaches its maximum range or hits a target, both
of which are easily "elementizable". Also, I don't like those barely
filled sub-folders in the projectile module, and the fact we've
divergent reusable and single use arrow types.
SmArtKar