* Micro-optimize qdel by only permitting one parameter (#80628)
Productionizes #80615.
The core optimization is this:
```patch
- var/hint = to_delete.Destroy(arglist(args.Copy(2))) // Let our friend know they're about to get fucked up.
+ var/hint = to_delete.Destroy(force) // Let our friend know they're about to get fucked up.
```
We avoid a heap allocation in the form of copying the args over to a new
list. A/B testing shows this results in 33% better overtime, and in a
real round shaving off a full second of self time and 0.4 seconds of
overtime--both of these would be doubled in the event this is merged as
the new proc was only being run 50% of the time.
* Micro-optimize qdel by only permitting one parameter
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* [no gbp] Jump jets activate a linked jetpack in a more sensible way (#78296)
## About The Pull Request
fikou pointed out that the code I wrote not only wasn't reliable on
destroy but also was overengineered
but only _after_ he merged it 😠
now we just ask the jetpack module if it is on rather than using a weird
trait
## Changelog
not player facing
* [no gbp] Jump jets activate a linked jetpack in a more sensible way
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* Nuclear Operative Jump Jets (#78088)
## About The Pull Request
This PR gives operative MODsuits access to "jump jets".
This is an activated module (starts pinned) with a 30 second cooldown
which removes your personal gravity for 5 seconds and (if possible)
pushes you upwards by one z level. In combination with your regular
jetpack this allows you to fly over gaps, and (most importantly) out of
pits such as you may inadvertently find yourself wandering into on
Icebox.
I have a few other changes I want to make specifically targetted at the
experience of Icebox station destruction causing people to fall several
z levels and get trapped, but this is the first one.
You have to stand still for 1 second to activate the jump jet. This is
because jetpack movement without gravity is actually usually faster than
an operative will walk, and I don't want them to just toggle it as a
sprint button while running around. If people find other tactical uses
for this though I think that's cool.
This module currently isn't available to crew on the tech web, although
maybe someone could add it later if they wanted to. It's not quite so
useful if you don't _also_ have a jetpack though.
I bumped the available complexity of the suits I attached it to up by
the complexity cost of this module so it's not taking up previously
available space.
## Why It's Good For The Game
It's funny when the whole ops team falls in a hole after an explosion
they caused and gets stuck in there fighting Snow Legions but they
should probably have some method for dealing with that.
It also lets them pop back up from the tram hole, a risky proposition
because any flying mob hit by the tram dies almost instantly.
## Changelog
🆑
add: Operative MODsuits now have an attached "jump jet" which sends you
upwards and allows you to use your jetpack under gravity for a few
seconds, perfect for navigating the pits and valleys of Icebox Station.
/🆑
* Nuclear Operative Jump Jets
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* Fixes a bunch of callbacks that were being qdeleted, and code cleanup (#77904)
## About The Pull Request
Continuing the work of
https://github.com/tgstation/tgstation/pull/77850.
it started with finding one that was being missed and causing a
runtime...then I noticed a whole lot more. While I was doing this I
found callbacks that weren't being nulled in `Destroy()`, so I added
that wherever I found these spots as well as some general code cleanup.
There were a lot more of these than I initially hoped to encounter so
I'm labeling it as a refactor.
## Why It's Good For The Game
Fixes lots of runtimes, improves code resiliency.
## Changelog
🆑
refactor: fixed a bunch of instances of callbacks being qdeleted and
cleaned up related code
/🆑
* Fixes a bunch of callbacks that were being qdeleted, and code cleanup
---------
Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com>
* Adds error on qdeling callback, fixes errors this causes (#77850)
## About The Pull Request
You shouldn't ever qdel a callback. If you don't want to own it free
your ref (remove it from a list/set it to null). When all refs are
cleared it'll get cleaned up by byond itself
* Adds error on qdeling callback, fixes errors this causes
* Update cell_component.dm
* Update acid.dm
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* Jetpack component & Modsuit module signal clean-up & fixes (#76133)
## About The Pull Request
1. Removed the `get_mover` callback, the mover can be retrieved during
activation itself
2. Fixes#76116
the user is passed correctly during activation & deactivation same for
modsuit modules and this also fixes the same bug for
`/obj/item/organ/internal/cyberimp/chest/thrusters` as it's signal was
also not registered correctly with the user
3. Timestop module on `on_module_triggered()` accepts user as 2nd param
## Changelog
🆑
fix: jetpack modules work on mod suits again
fix: jetpack cyber implants also work
refactor: removed `get_mover` callback, user is retrieved during
activation
refactor: timestop module on `on_module_triggered()` accepts user as 2nd
param
/🆑
* Jetpack component & Modsuit module signal clean-up & fixes
---------
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
* Fixes stowing suit storage jetpacks when retracting modsuit chestplates (#75844)
## About The Pull Request
This is a bizare bug I discovered while trying to develop another
feature, so let's just get into the reproduction steps:
- Wear a modsuit and extend it's parts
- Put a jetpack in the suit storage slot and turn it on. Currently, the
only jetpack that fits in the storage slot on TG is the captain's
jetpack.
- While the jetpack is activated, deactivate your modsuit using the UI,
which stows the jetpack into your storage module automatically.
- This fails to unregister some signal thing because it can't find the
user.
My fix *could* be shitcode, so any feedback would be appreciated.
Jetpack activation and deactivation signals now pass a user.
`/datum/component/jetpack/proc/activate(datum/source, mob/user)`
`/datum/component/jetpack/proc/deactivate(datum/source, mob/user)`
Some jetpack `pre_move_react` thing now has a check to see if it's
argument is null.
```
if(!trail)
return FALSE
```
## Why It's Good For The Game
Stops a crash/runtime.
## Changelog
🆑 stonetear
fix: jetpack signals now pass a user argument. This fixes an error when
automatically stowing a captain jetpack into your modsuit.
/🆑
* Fixes stowing suit storage jetpacks when retracting modsuit chestplates
---------
Co-authored-by: Stonetear <89315023+Stonetear@users.noreply.github.com>
* [NO GBP] Jetpack and spacedrift: Fixes and niceties (#66628)
* Jetpack and spacedrift: Fixes and niceties
Ok so when I ported spacemovement onto movement loop,
I neglected to port this behavior that existed to support jetpacks.
Basically, if something that lets you move while spacedrifing
completes a move while you're spacedrifting, the
drift should "disable" to let it complete, and then later restart.
I neglected to add support for that, so that's what this does.
There's some other stuff going on here, mostly things to let jetpacks
ignore some of drift's extra behavior, since when a jetpack is not on
stablized, we want both to coexist.
It's a bit of a mess, I'm sorry about that.
Oh and at temporal's suggestion I've moved the visual_delay set from
newtonian move to an istype on the drift component, that was a good
idea, thanks quiet
* Makes dropping a pull while drifting carry the momentum into the pulled thing\
* Adds some extra context to Process_Spacemove, fixes a bunch of stupid
space bugs
It used to be, if you called Process_Spacemove with a direction, it
assumed you were an "action", so a client or mob trying to move in a
direction.
Unfortuantely for it, I needed to be able to use direction to make mob
pull drifting work. So we now actually pass in a second variable
called continuous_move, which tracks if this Process_Spacemove is on
behalf of a continuous move or not
In addition to this, I've added logic to bumping "off" someone to
prevent backbumping if that makes sense, since the bump is in the form
of a newtonian move that's run before the thing that's bumping actually
moves, we need some way to exclude it from holding the other object in
place.
* Adds a jetpack component, uses it to unify all three versions of
jetpacking
I hate you fikou
There were three copies of the same behavior, which made it hard to fix
stuff. Let's just componentize it
* Fixes jetpacks stabalizing even without fuel
This is mildly hacky. The real fix is to do this with events, but I
really don't wanna bend my brain like that. This'll do
* Ensures turn_off always has a user)
* Shut pu
* Bulky drags no longer effect your movespeed in space, fixing a consistency issue between them and all other forms of drags
* Removes some redundant code, cleans up some messy stuff
* Removes redundant safety checking from jetpack code
* see above
* Removes redundant signals
* [NO GBP] Jetpack and spacedrift: Fixes and niceties
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
