Commit Graph

14 Commits

Author SHA1 Message Date
SkyratBot
2e7ad10f7e [MIRROR] Lemon fixes ci [MDB IGNORE] (#24942)
* Lemon fixes ci (#79384)

## About The Pull Request

Sets up moveloops to better catch issues with duplicated loops

Letting people modify the timer var AND have it track what bucket we're
in was a bad idea.
So instead let's store the queued time separate. Also makes
allowed_to_move return true/false instead of flags

This fixed? the null loop issue locally, I honestly have no damn idea
why. I'm gonna be working on the rest of ci here, left trackers so if it
pops up between now and merge I'll know what the issue is.

---------

Co-authored-by: John Willard <53777086+JohnFulpWillard@ users.noreply.github.com>
Co-authored-by: Emmett Gaines <ninjanomnom@ gmail.com>

* Lemon fixes ci

---------

Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: John Willard <53777086+JohnFulpWillard@ users.noreply.github.com>
Co-authored-by: Emmett Gaines <ninjanomnom@ gmail.com>
2023-11-12 11:25:49 -05:00
SkyratBot
6dfe17306c [MIRROR] Pulls apart the vestiges of components still hanging onto signals [MDB IGNORE] (#21738)
* Pulls apart the vestiges of components still hanging onto signals

* update modular

---------

Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
2023-06-18 13:18:23 +00:00
SkyratBot
ff12ce83f4 [MIRROR] Late adjustments to my previous move_loop PR. [NO GBP] [MDB IGNORE] (#21730)
* Late adjustments to my previous move_loop PR. [NO GBP] (#75778)

## About The Pull Request
Lemon guy was a bit too late in reviewing #75732 because it got already
merged by someone else, and I too hadn't managed to make some adjustment
to that PR in time.

This PR applies suggested changes, turns a simple proc into a macro, and
makes it so that also waddling, squeaky shoes and swivel chair sounds
don't running when moved by conveyor belt.

This doesn't stop squeaking from happening when other
conveyor-belt-moved objects or mobs cross its tile. That'd be hacky and
I'm not here to fight sfx-spamming machines.

## Why It's Good For The Game
These are changes that should have been included in #75732 but couldn't.
See that PR for the general idea.

## Changelog

🆑
fix: waddling, squeaky shoes and swivel chair sound effects no longer
run when moved by conveyor belt.
/🆑

---------

Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@ users.noreply.github.com>

* Late adjustments to my previous move_loop PR. [NO GBP]

---------

Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@ users.noreply.github.com>
2023-06-10 19:27:42 -07:00
SkyratBot
fd20f69744 [MIRROR] Being moved around by conveyor belt or tram no longer plays footsteps and wheelchair sounds. [MDB IGNORE] (#21562)
* Being moved around by conveyor belt or tram no longer plays footsteps and wheelchair sounds. (#75732)

## About The Pull Request
More or less a triviality, currently footstep/wheelchai sounds are
played even when the mob is moved by a conveyor belt, or riding the
tram. This PR puts an end to that.

To clarify, this doesn't stop these sounds from being played if you're
walking/running/rolling along or against a belt, or inside the tram.

But more than that, I made this PR because, afaik, we don't have a good
way to tell if a given movement proc chain was caused by a move loop or
not, and I need one for something I'm working on. This is more of an
implementation and reason for this PR to be made.

Tested, no issue. Waiting for a review, specially from @ LemonInTheDark,
since they're the mind behind the movement loop code. Hopefully I'm
right saying what I said.

## Why It's Good For The Game
This fixes a consistency issue (if it can be called such) and the lack
of a simple way to tell if a movable is being moved by a move loop
outside of its own code.

## Changelog

🆑
fix: Being moved around by conveyor belt or tram no longer play
footsteps and wheelchair sounds.
/🆑

* Being moved around by conveyor belt or tram no longer plays footsteps and wheelchair sounds.

---------

Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
2023-06-07 09:00:24 -07:00
SkyratBot
83e3915015 [MIRROR] Makes some improvements to how AI can use JPS with movement loops [MDB IGNORE] (#19151)
* Makes some improvements to how AI can use JPS with movement loops (#72685)

## About The Pull Request

This PR makes some changes to how JPS is used in movement loops, as it
was causing a variety of issues:

- Fixed some code where JPS would fail because the path is still being
made. Instead, the movement loop will now wait.
- Reduced the subsystem wait for the pathfinder subsystem from 2 seconds
to 0.1 seconds. @ LemonInTheDark told me that this is better, I'll update
this with a better explanation once I squeeze it out of him :D
- Allows you to provide an initial path to the movement loop, in case
you pre-calculated one while making a plan.

## Why It's Good For The Game

Makes working with JPS a bit easier when making AI.

---------

Co-authored-by: Capybara <Capybara@ CapybaraMailingServices.com>
Co-authored-by: Jeremiah <42397676+jlsnow301@ users.noreply.github.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@ users.noreply.github.com>

* Makes some improvements to how AI can use JPS with movement loops

---------

Co-authored-by: CapybaraExtravagante <110635252+CapybaraExtravagante@users.noreply.github.com>
Co-authored-by: Capybara <Capybara@ CapybaraMailingServices.com>
Co-authored-by: Jeremiah <42397676+jlsnow301@ users.noreply.github.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@ users.noreply.github.com>
2023-02-08 02:04:31 +00:00
SkyratBot
581b38c1a8 [MIRROR] Fixes a bug with drifting improperly stopping [MDB IGNORE] (#18626)
* Fixes a bug with drifting improperly stopping (#72588)

## About The Pull Request

You would hold a direction when you hit a wall, step, have the newt move
blocked by your still living component, and then sit there floating In
the last fix I did here I removed an unregister off loop pausing, which
was leading to conflicting component additions and so runtimes.

I've moved it to an unreg off loop deletion only, to avoid the old
runtime and still preserve the existing desired behavior

## Why It's Good For The Game

Fixes stepping after a drift movement. It looked really dumb and now
it's gone
Fixes https://github.com/tgstation/tgstation/issues/71454

## Changelog
🆑
fix: You can now properly start drifting after moving out of a drift
/🆑

* Fixes a bug with drifting improperly stopping

Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
2023-01-10 07:33:18 -08:00
Zonespace
f7c26bbf25 515 Compat (#17465)
* ONLY SKYRAT CHANGES

* ACTUALLY SKYRAT CHANGES

* yolo, revert later

* Update alternate_byond_versions.txt

Co-authored-by: AnturK <AnturK@users.noreply.github.com>
2022-11-15 06:59:06 +00:00
SkyratBot
4faaa0d665 [MIRROR] Fixes a spurious runtime off the drift component [MDB IGNORE] (#15815)
* Fixes a spurious runtime off the drift component (#69345)

* Fixes a spurious runtime off the drift component

If a loop is made non active, then we end up allowing for double
applications of the component, which throws errors because the old
component (and it's loop) still exist by that point.

This resolves that

* Fixes a spurious runtime off the drift component

Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
2022-08-25 00:48:00 -04:00
SkyratBot
4af0dd0b8f [MIRROR] addresses reviews on the tram pr made after merge, fixes diagonal movement bugs [MDB IGNORE] (#14943)
* addresses reviews on the tram pr made after merge, fixes diagonal movement bugs (#68033)

* addresses reviews on the tram pr made after merge, fixes diagonal movement bugs

* wew

Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
2022-07-19 00:51:33 +00:00
SkyratBot
18a56ffeeb [MIRROR] (code bounty) The tram is now unstoppably powerful. it cannot be stopped, it cannot be slowed, it cannot be reasoned with. YOU HAVE NO IDEA HOW READY YOU ARE [MDB IGNORE] (#14477)
* (code bounty) The tram is now unstoppably powerful. it cannot be stopped, it cannot be slowed, it cannot be reasoned with. YOU HAVE NO IDEA HOW READY YOU ARE

* fex

* fex

Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
2022-06-25 01:24:00 +01:00
SkyratBot
e416c5b573 [MIRROR] [NO GBP] Jetpack and spacedrift: Fixes and niceties [MDB IGNORE] (#13754)
* [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>
2022-05-20 14:41:47 +01:00
SkyratBot
a74758af0e [MIRROR] Space drifting fixes and cleanup [MDB IGNORE] (#11801)
* Space drifting fixes and cleanup (#64915)

* Fixes infi pushing off something in space

Right now you can just push "into" a dense object forever, and depending
on your move rate, just kinda glide

We can fix that by checking if we're trying to push "off" something
we're moving towards

* Makes pushing off something shift it instantly

Currently if you kick off something in space it waits the delay of the
move to start drifting. Looks dumb, let's not

* Updates backup movement to properly account for directional windows. GOD I HATE DIRECTIONAL DENSITY SHOOOOOT MEEEEEEEEEEEEEEEEEEE

* Uses range instead of orange so standing on the same tile as a directional counts properly, rather then suddenly entering a drift state. I hate it here

* Ensures all args are named, updates implementations of the proc with the new arg

* Space drifting fixes and cleanup

Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
2022-03-01 06:48:45 -05:00
SkyratBot
015020189b [MIRROR] Fixes funky magic item teleportation [MDB IGNORE] (#10865)
* Fixes funky magic item teleportation (#64263)

Space drifting "listened" for moves outside of its expected range, and if it saw them it would self delete
The problem is it registered for this behavior in drifting_start(), which was intended to be called by the MOVELOOP_START signal

But because that signal was fired as a consequence of move() being called, we never registered the signal
So if you took an item out of your pack, when it hit the ground it would get the drifting component
Next tick it would be drift moved to its intended location, the move would "fail", and then it would stop
This lead to items being visually in your inventory, but not functionally
Which leads to a lot of really weird behavior

Oh and I added a var to moveloops that's just "are we running" to make solving this class of issue easier

* Fixes funky magic item teleportation

Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
2022-01-21 10:12:38 +00:00
SkyratBot
0acc853c91 [MIRROR] Adds a movement looping system, replaces inbuild procs and spacedrift with it [MDB IGNORE] (#10749)
* Adds a movement looping system, replaces inbuild procs and spacedrift with it (#62567)

* Adds a subsystem to handle automated directional movement, replaces all instances of walk_towards with it. Makes meteors and immovable rods not drift in space, and makes immovable rods more destructive. Note, I've opted not to use byond's method of moving towards something, which is effectively Move(src, get_step(src, get_dir(src, target))) as it's cringe and doesn't make a smooth line. I've replaced it with a autoupdating rise over run setup, read the code for more details

* woop forgot the subsystem

* Documentation, contributing.md entry, and some cleanup

* Makes the moveloop datum more oop friendly, sets us up for a lot of conversions

* Converts the curseblob and walk_away() to the subsystem

* Changes the default for override from FALSE to TRUE

* converts walk() over, still need to add a replacement proc for it, but we didn't actually have anything that used the raw proc

* converts the rest of walk_to() over, nearing the end now

* cleans up some errors

* Fully documents everything, fills in some missing movement types, uses the power of oop to make things cleaner, and typepaths longer

* Finishes the contributing.md stuff

* Done

* Fefaults -> Defaults, can you tell I wrote this at 1AM?

* resolves bubblegum issues

* Roh's suggestions

Co-authored-by: Rohesie <rohesie@ gmail.com>

* Cleanup

* Hey lemon, did you know that Destroy() lives on datums? ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

* Converts over the discrepencies created in my absense

* HAHA FUCK YOU I PAY MY DUES

* Whoops lost some stuff in the merge

* Converts the system from seconds to deciseconds to make dealing with the api more sane

* Some stuff I missed

* Makes movement an inheritable subsystem type, splits the moveloop file into two, one for the subsystem, and one for the datums

* Makes a subsystem that handles directing movers out to other subsystems. It's a bit bad right now, but it's a
good first step. I think I'll move the move loop datum to a lazy var on mobs instead of an assoc list, don't
like lists.

Also makes the movement procs global, I'll move em to the /movement subsystem at some point or something like
that

* Converts the existing uses of the procs over to the new format

* Adds support for subsystem precedence, so a type of A can override type B.
General cleanup, still kinda in debug mode but it's getting better

* I'll admit I'm not too familiar with this, but I think it will work

* Adds starting logic so movement types "pausing" makes any sense
Redoes how waiting is handled to make it based on world.time directly. I don't remember why. I think it's better
this way.

Adds a drifting movement type, moves space drift over to it.
Needs severe work before it's ready, too much info stored and modified on the moving object, see comment
Starts work on making drifting smooth

* Moves almost all space drifting vars over to signals on the movement datum
Properly implements glide size stuff for both the subsystem and the loops. Space drift will be smoother now.
It's not perfect, but it'll work just fine for now

Adds a way to override a client'd mob's glide size mid move, uses it to make entering a spacedrift look right
Adds a way to delay a client move outside of just move_delay, meant to be used for long periods, and setup such
that it doesn't make inputs persist

Adds flags to movement loops, alongside MOVELOOP_OVERRIDE_CLIENT_CONTROL, which blocks client movements while
the loop is firing, and for it's visual delay after

This means you can't exit a space drift until you hit the actual wall. This feels a lot better

Some general logic stuff, move() will return true/false if it succeeded or failed
Adds a stop_loop() proc that's called when a move loop is no longer active

Suck my nuts

* Moves precedence to the loop instead of the subsystem

* Moves drifting into a component, this lets me explictly block input after the move loop ends, so people can't
move the moment they functionally move onto a new tile
This is a bit underdeveloped currently, but that's a problem for another day

Cleans up some uses of move procs, fixes runtimes in metoer and curseblob code
Adds signals for stopping/starting a move loop, sending one for destroy is redundant.
Moves existing event signals from the movable being acted on to the loop itself, makes more sense this way
Makes the move handler return the created loop up the chain so we can register to it
Fixes a logic error in loop contesting code that lead to loops never actually being removed from subsystems
because they didn't know they should be.
Properly changes lifetime from a time to stop, to functionally an amount of moves to complete before stopping
Adds some new signals for pre/post loop process. This is to better tie into components.

I decided I didn't like the idea of tying all functionality to the loops themselves
The loop decides functionally how to move, components or just tied in signals can decide when/when not to move
and can modify properties of the loop

Making a new loop for things like atmos drift, something I'm interested in tackling in the future, seemed silly

* Moves movement procs directly to the subsystem for better namespacing or whatever

* Moves movement packets onto /atom/movable, no longer need the debugging
I've decided to not just put their contents fully onto atom movable, since it makes debugging on live much
harder, can't sdql for them anymore.

Fixes a runtime in meteor code, properly this time
Fixes a logic error in stop_looping
Makes move manager NO_INIT, because well, it doesn't init

* Commits human sin, makes Recover() work properly for movement subsystems

* Fixes immovable rod orbits not always working, they were returning too early in moved and fucking up the var we use to track move count, and thus not sending a signal properly

* Reworks the curseblob to use signals more, and to not use override

* Missed this in the movement ss commit

* Removes override, makes having a higher or equal precedence take its place

* Updates documentation

* Cleans up some unused defines

* Nukes the unused flags option

* Whoops forgot to qdel check

* Removes an unused var I had for client move prevention before I started using a component

* Let's do this properly

* Modernizes meteor code to better match how explosions actually work currently

* Some more cleanup

* Cleans up effect code a little bit
Nukes the effect system's sleep loop, we use movement loops instead
As a part of that, instead of 1 timer per effect spawned, we react to loop failure and make it 1 timer per
effect system
This should reduce the amoumt of slowdown we see after mass lighting break

It's not everything, we're still making a timer per spark effect, but it cuts things down significantly

* Updates explosions to not sleep

* Adds support for modifying a loops delay post process, makes extinguisher code suck less then it does currently, nukes some more sleeps and timer loops

* Converts water tank resin over to move loops rather then sleeps, minor behavior change mind, the cooldown starts on fire rather then on land, but I think that makes more sense anyway

* compile and runtime fix

* Fixes some runtimes, cleans up some code, ensures feature parity when it comes to logging

* Prevents resin foam from space drifting

* Adds support for flags back into the system, I need it for reasons

* Updates move_towards to fix some bugs and resolve some inconsistent behavior, implements a flag that makes a loop's first move start instantly

* Fixes extinguishers not actually transfering any reagents

* Converts sprays to the new system. This does actually minorly change behavior, in that I've changed the order of spray actions from step -> sleep -> wash to step -> wash -> sleep, but I'm not terribly torn up about it because frankly I think it feels better

* Converts grav catapults over to the new system

* Converts trays over to moveloops

* Converts robot streaking to move loops, the other two coming soon

* Compile you won't. Also fixes a behavior issue with oil streaks

* Does directional step_to properly, cleans up the other two streaking types

* Converts step_trigger over, not that it's actually used anywhere. Changes how stoping a move works, you need to explicitly qdel, other the step is just considered to be ignored. This will make life easier later

* Adds a jps movement loop. It's a bit bloaty, id is stupid, but it'll work just fine

* Makes the system support passing in a datum that's just used as extra context for the move. The hope is this makes signalizing things less of an absolute headache

* Begins the conversion of ai movement datums to movement loops

* These two are reasonably simple, only weird thing I'm doing is A: Not allowing target hotswapping, which I hope none is doing, and B: passing the controller into the move loop as extra context so things work properly

* JPS is a bit more complex, partially because the old implementation was a bit weird. 2 major things. 1: I'm dropping what I think was a redundant behavior minimum distance check from the premove bit of logic, since I'm pretty sure it didn't do anything. 2, instead of just stoping the step in an error state like being pulled, we count it against our max move total

* Audit

* Moves most forced movement to the framework, adds some components to make things nicer

* Implements a flag that makes the loop always operate, regardless of precedence and without impacting any other loops

* Moves movement subsystems into the right folder

* Hey potato what if you had two procs that did the same thing and one called the other? Wow it's useless

* Merges slipping and force movement

* Converys conveyors over to the system. It's a bit fragile, but I think it's totally worth it to save the sleep loop

* Precedence -> Priority, cleans up some logic errors, makes priority highest to lowest instead of lowest to highest, straight cleans some code up

* Makes poly and bubbles ignore spacedrift, now that precedence actually functions properly. I'm likely missing cases of this, will deal with it later

* Depression, thy name is linter

* Fixes linter, and hopefully fixes the runtimes in ci too

* Wew

* Sets sprays and extinguishers back to legacy, since people do actually seem to have noticed

* Spelling errors my beloved

Co-authored-by: Kylerace <kylerlumpkin1@ gmail.com>

* More detail, moves return descriptions

* Converts transit tubes to the system?

* Adds the glide size modifier. Not honestly sure that this should be default, considering how crummy it makes things look for normal walking, but it's useful as hell here

* Adds a force move in dir template, actual support for fast initial steps (wtf old me) and a helper proc for setting delay

* Cleans up displosal code a bit, I thought about adding it to the system but it would functionally be just 'disposal loops'. Maybe I'll make a template subtype? not sure how I want to handle stuff like this

* Cleans up mob movement a bit

* Let's use the controller's visual delay

* Makes the resin thrower nicer, cries

* Cleans up some comments, replaces an implicit world.icon_size with an explicit one, fixes up a typecheck

* typecache instead of double istype. Can't do much about the !atom/movable, list would be too big I feel

* hhh

* bro wtf

* Documents the why of SS_TICKER

* Puts SSmovement on SS_TICKER. Lets us support tick steps

* Cleans up the charge action. Makes it use moveloops

* Fixes CI? kinda worried that this just got dropped

* Converts disposal pipes to move loops. They stutter a bit more then usual as of now, hoping that's a me thing, if it's not I'ma look at uping the priority of the base subsystem

* Moves the move subsystems off background, puts some on ssticker

* Prevents some things that shouldn't move in space from moving in space

* Documents the general form and usage of the system

* Virgin one vs chad once

Co-authored-by: Kylerace <kylerlumpkin1@ gmail.com>

* Removes unneeded check

* Moves appropriate movement subsystems into SS_BACKGROUND. Removes redundant SS_KEEP_TIMINGs

I do want the behavior of SS_TICKER, which at this point is tick based waits, and ignoring overtime when
calculating next fire.
Since honestly, these subsystems should ignore overtime in regards to next fire, the cost of moving A may be
nothing compared to the cost of moving B.

* Makes the MODULUS macro use floor. I knew our coders would never let me down, glad this exists, thanks ninja
Fixes teleporting caused by shitty round() behavior, adds a "you hit your target" case to homing loops

* Converts blood splatters to move loops, that'll do it

Co-authored-by: Rohesie <rohesie@ gmail.com>
Co-authored-by: Kylerace <kylerlumpkin1@ gmail.com>

* Adds a movement looping system, replaces inbuild procs and spacedrift with it

Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Rohesie <rohesie@ gmail.com>
Co-authored-by: Kylerace <kylerlumpkin1@ gmail.com>
2022-01-18 00:54:06 +00:00