Ports projectile refactors from TG (+other stuff)#10962
Ports projectile refactors from TG (+other stuff)#10962TheColorCyan wants to merge 95 commits intoMonkestation:masterfrom
Conversation
…sus bolts in CI) #87534
Massive cleanup/pseudo-refactor of projectile and projectile-adjacent code. One letter variables, weird logic, some runtimes, all of that. Atomized in a separate PR from the actual refactor so we don't end up with a 5k line PR. Makes the code possible to work with before I nuke pixel_move and kevinz units:tm:
~~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. * 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:tm: 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> 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 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. :cl: 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! /:cl:
So, the main issue was that the variables for the embed element wouldn't set when attached to a projectile but only on items for some insignificant reason, which means it'll spawn the shrapnel yes, but won't embed it since the chance is null/zero. I read the code over and over and over with the assumption that something like this wouldn't have been done, yet it was. As for the secondary issue, because of how embedding works, the casing types of arrows and harpoon aren't spawned when hitting a non-carbon or reaching their maximum range. So, I'm re-enabling the reusable arg/var for the caseless component of harpoons and arrows, and modifying the `projectile_drop` to not drop their payload if the embedding component would already do that, so we avoid duping.
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 This will fix #77187. Perhaps buff harpoons and arrows a little but meh. :cl: 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). /:cl:
… the arms race and the sniper's art. (#83934) Replaces the Particle Acceleration Rifle, or the Beam Marksman Rifle, with the Event Horizon Anti-Existential Beam Rifle. In short, it shoots black holes. It takes five cores to make. It pretty much kills everything you point it at and their immediate bystanders as well. You can do this from the relative safety of a whole four screens away thanks to it having a scope. There can only ever be one vortex anomaly made in the round. The recipe, however, always requires the maximum number of cores that can be made in a round. If the number goes up for some reason (maybe someone wants to add more vortex items), so does the total number of cores needed to make an AEBR. Firstly; the beam rifle? Awful. Jank code. Bad performance. Ancient balancing considerations. Just too strong to bring out regularly against specifically blobs, but completely fucking useless against anyone else. So I'm hitting all these problems at once. I reduced a 600 line file to less than 60. I've removed all that bad code. I've also made it specifically unable to combat blobs at all because singularities send blobs off to safety. Secondly; this is maybe the first example of 'more cores = bigger power'. The rifle was already utterly trash to have around, and I just didn't think the way it worked currently could really excite anyone enough to go on a big ol' quest to get it. Solution? You will cause a shuttle call if you get this weapon. :cl: add: Replaces the Particle Acceleration Rifle with the Event Horizon anti-existential beam rifle. It shoots black holes. You can make this in-game. That's right, YOU! balance: Only one vortex anomaly can be made in a round. /:cl: --------- Co-authored-by: Jacquerel <hnevard@gmail.com>
code/game/objects/effects/temporary_visuals/projectiles/projectile_effects.dm
Outdated
Show resolved
Hide resolved
code/modules/mob/living/simple_animal/hostile/mining_mobs/elites/herald.dm
Show resolved
Hide resolved
Test merge deployment history:Test Merge Deployed @ 03/07/2026 11:49:34 +00:00:Server InstanceMonkestation Merged Bysirnightknight RevisionOrigin: 4de0d25 Test Merge Updated @ 03/07/2026 11:52:22 +00:00:Server InstanceMonkestation Merged Bysirnightknight RevisionOrigin: 461cb70 Test Merge Updated @ 03/07/2026 13:14:55 +00:00:Server InstanceMonkestation Merged Bysirnightknight RevisionOrigin: 36a26df Test Merge Updated @ 03/07/2026 15:05:39 +00:00:Server InstanceMonkestation Merged Bysirnightknight RevisionOrigin: 93d1039 Test Merge Updated @ 03/07/2026 20:29:39 +00:00:Server InstanceMonkestation Merged Bysirnightknight RevisionOrigin: 93d1039 Test Merge Updated @ 03/07/2026 21:47:01 +00:00:Server InstanceMonkestation Merged Bynotghosti RevisionOrigin: 7cb0112 Test Merge Updated @ 03/08/2026 17:09:30 +00:00:Server InstanceMonkestation Merged Bysirnightknight RevisionOrigin: 9bbbdde Test Merge Updated @ 03/08/2026 21:14:29 +00:00:Server InstanceMonkestation Merged Bysirnightknight RevisionOrigin: 9bbbdde |
|
This doesn't add TG's horrendous space movement change(s) from [84869], just the tether fixes and such, right? That was still horrendously buggy and unfun last I checked. |
yeah its tether stuff only |
About The Pull Request
Ports tether module refactors and fixes from
tgstation/tgstation#84869
Ports event horizon because it removes code that has errors (also its funnny)
tgstation/tgstation#83934
Ports gun code refactors:
tgstation/tgstation#76335
tgstation/tgstation#77450
tgstation/tgstation#84246 - bayonet stuff
tgstation/tgstation#84247 - fix managize overflow
tgstation/tgstation#84599 - embed refactor
tgstation/tgstation#87224
tgstation/tgstation#87534
tgstation/tgstation#87628
tgstation/tgstation#87740
tgstation/tgstation#87803
tgstation/tgstation#88072
tgstation/tgstation#88511
tgstation/tgstation#88893
tgstation/tgstation#89616
tgstation/tgstation#92166
tgstation/tgstation#92219
and many more fixes for runtimes and stuffs
Why It's Good For The Game
smoother stuff and less lag
Testing
Tested with most guns in debug box
Tho, some monke additions may still have errors so need to test on live
Changelog
🆑 Ghommie, SmArtKar, TheColorCyan
refactor: projectiles and embeds were severely refactored, report any issues
add: (necromanceranne) Replaces the Particle Acceleration Rifle with the Event Horizon anti-existential beam rifle. It shoots black holes. You can make this in-game. That's right, YOU!
balance: (necromanceranne) Only one vortex anomaly can be made in a round.
refactor: (Whoneedspacee) Wendigos abilities have been changed into actions that can be added to any mob.
add: (SmArtKar) You can now craft tether anchors, which can be secured with a wrench and attached to with right click. They won't let you drift into space and you can adjust tether length/cut it via lmb/rmb/ctrl click on the wire.
add: (SmArtKar) MOD tethers now remotely place and connect to tether anchors instead of throwing you at where they landed.
balance: (SmArtKar) MOD tethers can now be used in gravity
/:cl:
Pre-Merge Checklist