Commit Graph

8 Commits

Author SHA1 Message Date
SmArtKar
80bd414237 Removes spacemove crashes/impacts at high speed (#92284)
## About The Pull Request

Something changed in spacemove loop code recently which caused infinite
recursions through throw code. This has been a rather bad mechanic
already, and I believe that it warrants removal alongside newtonian
zero-g physics in general - but for now lets just get rid of the part
that crashes the server.

## Why It's Good For The Game

We've pushed the speed limit to the point where you need to be firing a
SAW without a jetpack for a full minute to actually crash into
something, its a bad mechanic that doesn't bring much to the round
as-is.
2025-07-30 21:53:38 -05:00
SmArtKar
8d48f8d4d2 Fixes an 8 year old bug which colored your HUDs with you (#88667)
## About The Pull Request

Partially a port of
https://github.com/DaedalusDock/daedalusdock/pull/1163 which is a port
of my own code from bitbus
Closes #88579

Instead of manually setting hud images and positioning we now can use
set_hud_image_state which also updates their position to ensure that
they scale with the owner atom. HUDs had RESET_COLOR and RESET_TRANSFORM
but no KEEP_APART, so they were stuck with mobs all this time. I
replaced RESET_TRANSFORM with PIXEL_SCALE (shouldn't be reserved to mob
huds only to be honest) and added KEEP_APART, so that HUDs still
scale/rotate with their owner but don't inherit their color. Also fixed
the dragon issue, that's where this PR actually started.

Closes https://github.com/tgstation/tgstation/issues/45411

## Why It's Good For The Game

I don't want my HUDs to be pretty pink when I make a barbie Clarke.

## Changelog
🆑
refactor: Rewrote some of HUD code so they're no longer colored in their
owner's color
fix: Space dragons no longer turn invisible when toggling seethrough
mode
/🆑
2024-12-26 15:06:04 +01:00
SmArtKar
92d224d48f Fourth! Time's the Charm: Actually fixes jetpack race conditions this time around (#88492)
## 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
/🆑
2024-12-15 04:49:30 +01:00
SmArtKar
f58ebf1a6e Third Time's the Spessman: Solves jetpack struggles once and for all (#88317)
## 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.
/🆑
2024-12-07 00:15:36 +01:00
SmArtKar
e41b5acf8e [NO GBP] Fixes lattices causing spacemove jank (#87320)
## About The Pull Request
Lattices blocking space movement was handled on /atom/movable while my
comsigs were on /mob, thus making lattices overrule all force code. Mobs
now properly handle them via pushoff code.

## Why Is This Good For The Game
Lattices are very jarring to move along rn, this was not intentional.

## Changelog
🆑
fix: Moving along lattices in space with a jetpack on no longer causes
your screen to jerk
/🆑
2024-10-23 12:48:49 -07:00
SmArtKar
28bbca59b5 [NO GBP] Prevents walls from slowing your drifting down when you're moving in the same direction as your pressed movement key (#87142)
## About The Pull Request

Oopsie, this prevents walls from slowing your drift down if you're
pressing a movement key and moving in your intended direction

## Why It's Good For The Game
Smoother movement when you're moving near a wall with a jetpack or
tether or whatever really

## Changelog
🆑
qol: Jetpack movement near walls should be much smoother
/🆑
2024-10-11 18:00:36 +02:00
tonty
3f0b4abb8d Replaces world.icon_size (and some magic numbers) with defines (#86819)
## About The Pull Request

All usages of world.icon_size in code have been replaced with new
`ICONSIZE_X`, `ICONSIZE_Y` and `ICONSIZE_ALL` defines depending on
context

Replaces some "32" magic numbers with the defines

A few bits of code have been modified to split up x/y math as well

## Why It's Good For The Game

Magic number bad, code more readable, code more flexible and I'm told
there's an access cost to doing world.icon_size so minor performance
gains

## Changelog

🆑 tonty
code: made some code relating to the world's icon size more readable
/🆑

---------

Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
2024-09-29 13:28:32 +00:00
SmArtKar
ad111f4950 Spacemove refactor - Newtonian physics (#84869)
## 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.

![jetpack_500](https://github.com/tgstation/tgstation/assets/44720187/37b11cd8-2bd1-4640-ae0c-5e0cc505bf52)

**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.
/🆑
2024-09-26 02:49:54 -07:00