## About The Pull Request
Didn't run the check in stabilization code, also fixed a forgotten
comsig unreg
## Changelog
🆑
fix: Fixed moth wing stabilization working in zero-g as long as you keep
moving
/🆑
## About The Pull Request
A) Queue time can be null and it'll be valid for hotstarting loops
B) Pushoffs working even when you're moving feels much better
C) Jetpacks were having race issues with drift handlers because those
were also using comsigs which is a remnant of old code back when they
were components. Handlers should fire last, post-comsigs.
D) We should not be hard-blocking jetpack movement when doing final
slowdown step. Like really.
## Why It's Good For The Game
Jetpacks ACTUALLY don't suck this time around.
## Changelog
🆑
qol: Jetpacks should ACTUALLY feel better now
/🆑
## About The Pull Request
Moth wings prevent you from flying in gravity -> same check is used for
activation -> they're activated upon implanting -> unless you spawn or
get wings in zero-g you're screwed
Closes#88460Closes#88457
## Changelog
🆑
fix: Fixed moths only being able to fly if they spawn in zero gravity
/🆑
## About The Pull Request
This PR improves our jetpacks in 2 major ways: partially decoupling them
and intentional space movement from SSnewphys, and implementing
consistent pushoff speeds.
Currently jetpacks work by applying constant newtonian force whenever an
input key is held down by a client and stabilizing the movement every
time they get processed by SSnewphys which is an SS_TICKER subsystem,
which means that it attempts to fire prior to everything else and has a
wait of a single tick. This would be fine if we could guarantee that
there isn't another SS_TICKER subsystem with a higher priority that
constantly overtimes... oh right, that'd be the most important subsystem
of SSinput.
Newtonian impulses, both when starting a drift and when applying
continious force rely on SSnewphys to fire the loop, which can end up
not happening due to overtime in input (and is a frequent issue on
highpop). To circumvent this, newtonian impulses now forcefully fire
their drift loop regardless of SSnewphys, thus ensuring that the
movement always happens in the tick it was called (If you ask something
to move with an ``instant`` flag you'd expect it to move the same tick).
Second issue stems from the fact that jetpacks try to move you at your
movement speed, except when pushing you off objects they hijack normal
movement code that would've ran, resulting in a single tile of slow,
janky movement (Or, when moving along walls, making the controls feel
"sticky" and worse than what you'd have without a jetpack in the first
place). By forcefully applying enough force to make players move at
expected speeds, we can solve that issue.
Third issue stems from a minor mistake in SSnewphys processing order -
process() on jetpacks ran **after** moveloops have fired, so all
stabilization only applied next tick. I swapped fire orders around which
solves this problem too, although it won't be triggering much as
stabilization would now forcefully fire the related loop by itself.
https://github.com/user-attachments/assets/1068f68b-2cd1-49b0-bff0-1f79ed0aed5a
Also I've refactored wings to be jetpacks since they behave exactly the
same, which is a bit cursed if you think about it.
## Why It's Good For The Game
Jetpack movement is highly inconsistent in speed/smoothness, janky and
gets ruined by even a slightest amount of overtime in subsystems above
it - this should solve all of those issues.
## Changelog
🆑
qol: Jetpacks are significantly smoother and nicer to use now - and not
affected by lag anymore!
code: Cleaned up spacemove/jetpack code a bit and moved some common code
to helpers.
refactor: Wings are now... jetpacks. They behave exactly the same and
this should reduce the amount of copypaste code in spacemove
significantly.
/🆑
## About The Pull Request
I hate this timeline. What title says, makes jetpacks and wings allow
you to bump into things you're moving into.
## Why It's Good For The Game
This feels awful and requires you to stop pressing movement keys for a
moment before resuming movement to get out of the "stuck" state
## Changelog
🆑
fix: Fixed wings and jetpacks sometimes preventing you from opening
doors
/🆑
## About The Pull Request
Jetpacks will now prevent you from attempting to interact with objects
near you in zero G, preventing you from pushing lockers and people
around. This also makes jetpack movement ***much*** more smooth, as they
will activate at your first move, preventing jerky movement when pushing
off walls. Same applies to all wings which should help moth players with
new spacemove.
Thanks to iusedtoplayxbox on discord for providing details regarding the
issue.
## Why It's Good For The Game
Less jank = happier players
## Changelog
🆑
qol: Jetpack movement is now much smoother
/🆑
## About The Pull Request
This PR significantly enhances how zero-g movement works. Its no longer
locked to one of 8 directions, everything now has inertia and is
affected by weight. This means that throwing a piece of wire will no
longer completely reverse your movement direction, and that being thrown
out of mass driver no longer will slow you down to a halt at some point.
This leads to following gameplay changes:
* Guns now accelerate you. Ballistics have higher acceleration than
lasers, and higher calibers have higher acceleration than smaller ones.
This means that firing full-auto weapons in zero-g will make you drift
and accelerate significantly. While this can be a hilarious way to
travel in space, it makes using them trickier.
* Impacting a wall or an object while moving at high speeds will cause
you to violently crash into it as if you were thrown. Careful when
exploring!
* Jetpacks now have inertia. Changes introduced in #84712 have been
mostly reverted, although speed buff has been reduced to 0.3 instead of
0.5 (although this is compensated by new movement mechanics, so overall
speed should be roughly equal). All MODsuit jetpacks now possess the
speed boost. Advanced MODsuit jets (which has also been added back) and
captain's jetpack instead have higher acceleration and stabilization
power, providing much more precise control over your movement.
* Firing guns while moving on a jetpack will partially negate your
pack's acceleration, slowing you down. Non-advanced jetpacks'
stabilization is not enough to compensate for heavy caliber weaponry as
sniper rifles, shotguns or rocket launchers.
* You no longer instantly decelerate upon sliding along a wall. Instead,
it may take a few tiles if you are moving at extreme speeds. Passing
over lattices still allows you to grab onto them!
As space movement is angle-based instead of dir-based now, its much more
smooth than before due to using new movement logic.
Example of jetpack stabilization in action:
https://github.com/tgstation/tgstation/assets/44720187/6761a4fd-b7de-4523-97ea-38144b8aab41
And, of course, you can do this now.
**This pull request requires extensive gameplay testing before
merging**, as a large amount of numbers have been picked arbitrarily in
an attempt to keep consistency with previous behavior (guns and
normal-sized items applying 1 drift force, which is equal to what
everything applied before this PR). Jetpacks and impacts may also
require adjustments as to not be frustrating to use.
Closes#85165
## Why It's Good For The Game
Zero-G refactor - currently our zero-g movement is rather ugly and can
be uncomfortable to work with. A piece of cable being able to accelerate
you the same as a duffelbag full of items when thrown makes no sense,
and so does instantly changing directions. Inertia-based version is
smoother and more intuitive. This also makes being thrown into space
more of a hazard (possibly opening the door for explosive
decompressions?)
Jetpack inertia and gun changes - this is mostly a consequence of
inertia-based movement. However, zero-g combat being preferred during
modes like warops was an issue due to it negatively affecting everyone
without jetpacks which are in limited supply onboard. This reverts the
mobility changes which severely impacted space exploration, while making
zero-g combat more dangerous and having it require more skill to be a
viable option.
## What's left
- [x] Refactor moth wings to use jetpack code
- [x] Refactor functional wings to use jetpack code
- [x] Locate and fix a recursion runtime that sometimes occurs upon
splattering against a wall
- [x] Add craftable tethers and modify engineering MOD tethers to use
the same system
## Changelog
🆑
add: 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: MOD tethers now remotely place and connect to tether anchors
instead of throwing you at where they landed.
balance: MOD tethers can now be used in gravity
balance: Jetpacks are now inertia-based.
balance: Guns can accelerate you significantly in zero-g.
balance: All jetpacks now give you equal speed buff, however advanced
MOD ion jets and captain's jetpack have higher acceleration/deceleration
values.
refactor: Refactored zero-g movement to be inertia-based and utilize
angles instead of directions.
/🆑
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
This is a REALLY hot proc, takes up to like 2% of total cpu at highpop
Let's micro it then
First, clients do not go null at random. It's not predictable per say
but it is consistent.
We can use this understanding to remove a bunch of null checks here
For loops are expensive. So rather then doing one each keyLoop, let's
cache the client's intended move direction on the client. Simplifies
some other code too
There is no sense running a turn call if it would have no effect, let's
be more intelligent about this
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
refactor: Fucks with how movement keys are handled. Please report any
bugs
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
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.
## 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
## 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.
/🆑
## 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
/🆑
## 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
## 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
/🆑
## 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.
/🆑
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* 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
SmArtKar