## 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
~~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#71822Closes#78547Closes#78871Closes#83901Closes#87802Closes#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!
/🆑
## About The Pull Request
Added a unit test that checks if embed chance modification, embedding
and embed modification passing to shrapnel is correct.
There seems to be an inconsistent embedding failure right now that
@necromanceranne discovered, hopefully this can catch it further down
the line.
## Changelog
No player facing changes.
SmArtKar