mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-15 18:14:22 +01:00
masterfixes
43 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 CabinetOnFire
|
af8f69da13 |
Adds "Event Logging", or EVLogging, A new debug system that allows us to track individual datums and log events on a timeline (#96035)
## About The Pull Request This Pull Request adds a new logging system that uses a timeline to track and visualize important events for specific datums. This is done via a new window in which you can select a datum for tracking, which adds it to the timeline. If this datum implements the EVLOGGING macros, it can track important events onto this timeline. As an example, we can log whenever an AI is deciding to make a new path, if it decides to generate a new decisionmaking plan, it finishes an action, or it decides to target someone/something. We can select these events to see more information, and optionally get a snapshot of important variables at the time this event was logged (like the blackboard and current plan for AI controllers). You can also filter out specific events / track info, which is done via categories. Each event / piece of track info is given a category and if you disable a category all events / track info in that category is hidden. This lets you filter out things you might not care about. <img width="2346" height="1209" alt="image" src="https://github.com/user-attachments/assets/0763077c-e349-4c7c-b017-23d29e1d089b" /> _whoever thinks we didnt need advanced cleanbot logging is a noob_ In the video below I showcase how this works; https://file.house/7nsOiqdvmSTxlsk3fs-e8g==.mp4 A cleanbot is roaming the halls, I turn on the event logger, click the "pick target" button and click on the datum I'd like to track (the cleanbot). This results in the cleanbot now tracking its events. I spawn some dirt and the cleanbot decides to clean it, and I go through the events; You can see theres different events being listed, such as when the cleanbot starts targetting the dirt, when it cleans plan, when it makes it JPS path and every time it moves over it. The macros I've currently implemented are as follows: **EVLOG_TEXT(DATUM, CATEGORY, INFO)** Only adds text to the event logger window, no world-visuals EVLOG_LOCATION(DATUM, CATEGORY, INFO, TURF) Adds text to the event logger and adds an image to where that turf is. EVLOG_TURFS(DATUM, CATEGORY, INFO, TURFS) Adds text to the event logger and adds an image to each turf in the TURFS list EVLOG_LINES(DATUM, CATEGORY, INFO, TURF_A, TURF_B) Adds text to the event logger and adds a line from turf_a to turf_B EVLOG_PATH(DATUM, CATEGORY, INFO, TURFS) Adds text to the event logger and visualizes a path from A to B (same way as the pathfinding debugger, of which I moved the visualization before to SSPathfinder) In terms of performance, the logger is a singleton, and events are ONLY logged if 1. The logger is running 2. The datum has the DF_EVLOGGING flag. This means most of the time, logging an event is a single var lookup (Since the runner is off by default). The DF_EVLOGGING flag is off by default as well and has to be enabled by the event logger, or set temporarily by a dev in code. This system can easily be extended with more event types / visualization types as well. (I'm thinking of datumizing the ones I have now) The TGUI is still a bit of a mess, I would love some pointers because I'm not really good at react so I just kind of hit it with a hammer until it did what I wanted 😎 Also, all of this is based on VisLogging from Unreal Engine, so it will have some likeness https://unreal-garden.com/tutorials/visual-logger/ ## Why It's Good For The Game This system allows us to debug more complex systems (like basic AI) in an understandable and clear way. While the implementation cases are not super common right now, extending this system could make debugging these systems much more comprehensible, and hopefully lets more developers help us with improving these systems. (plus, we LOVE timelines) ## Changelog 🆑 CabinetOnFire refactor: Implements "Event Logging" an improved way for programmers to debug specific datums. /🆑 --------- Co-authored-by: Lucy <lucy@absolucy.moe> |
||
|
Lucy
|
79e7aa569e |
fixes up some math defines to use byond builtins instead of workarounds (#95652)
## About The Pull Request this translates some various - `FLOOR(x, 1)` -> `floor(x)` - `CEILING(x, 1)` -> `ceil(x)` - `SIGN(x)` define is gone, just uses the native BYOND `sign()` now. Also, the `MODULUS` define is just a wrapper for the [BYOND `%%` operator](https://ref.harry.live/operator/modulomodulo) now. would be nice if someone double checked to make sure there's no potential subtle oddities resulting from this. ## Why It's Good For The Game These procs presumably did not exist whenever the defines were written - and they are BYOND builtins, meaning it will just be, say, one `sign` instruction, instead of two comparisons and a subtraction. ## Changelog no player-facing changes |
||
|
LemonInTheDark
|
f2360d64fd | Gives subsystem controllers a bitfield def to make vv easier, renames their flags var (#95439) | ||
|
LemonInTheDark
|
9d14e327b5 |
Begins Improving Sparks/Flares Somewhat, Adds Animatable Light Overlays (#95362)
## About The Pull Request [Adds a visual tick helper, integrates it into SSmove and such](https://github.com/tgstation/tgstation/commit/e97035f9f74fad5c67c5bf19d8d5d3bb4bd476b4) Basically, if we do "stuff" during verb time then the next chance clients have to actually see it is on the next visual tick (rather then the normal "this tick"). This is cause clients get their next frame during maptick, and maptick runs before verbs. We want to be able to handle this properly because if you say, create an object and then move it on the same VISUAL tick (NOT game tick), it will just teleport instead of playing out the move. I don't want this for stuff like sparks, so we need a way to work around it. [Moves most users of the _FAST flag to _INSTANT](https://github.com/tgstation/tgstation/commit/6f96daac00519c69adc7554f52114798a65f3ad5) These are the kids that don't immediately spawn something and the move it, and we want to allow them to move actually as soon as possible (important for stuff like space) [Improves basic effect systems, makes their products delete when they stop moving](https://github.com/tgstation/tgstation/commit/172cb25d80ed34e1ec523172a1677fb524239fba) Moves some stuff out to getters or vars so children can better decide how long effects should last/how fast they should move. Uses this to clean up weird dupe code used by explosions. Makes all these effects delete on contact with something that stops them. I'm doing this because an effect just hanging in the air looks really really odd. Does have consequences for sparks that are already moving at a wall though, might need a better way to handle that. Makes all these effects use _FAST loops so they don't just hang in the air for a second on spawn Adds a setter proc on sparks for their duration, gonna use this to improve their effects some [Refactors overlay lights, adds support for animating their images](https://github.com/tgstation/tgstation/commit/3ad0083cf2b536df51a6d93dca40eac20c1d62d1) Implements light_render_source and relevant setters, this allows us to replace the components of an overlay light with basically whatever we want Refactors overlay lighting to handle its images more consistently, allowing us to hook into an image being modified Combining the two of these will allow us to consistently copy a light's image, modify it in some way, and then relay that modification back down. Allowing us to animate it or do more advanced effects painlessly Also, fixes ranges of 1 or less not rendering at all on initial set (thank you kapu) [In which I get fed up and add a macro helper for UID generation](https://github.com/tgstation/tgstation/commit/aab48b03d407104d4f9cf9acb034494237def911) [adds vv hooking for all existing lighting vars](https://github.com/tgstation/tgstation/commit/b81c6200a0d74c36b440aa3f4c1f22c422090a2d) [Upgrade effect system's dir picking to avoid duplicates when possible](https://github.com/tgstation/tgstation/commit/18b622586b509c6be4c4bca4e3e7c175ad75fe91) [Uses the technique described above to animate spark's lights out as they move](https://github.com/tgstation/tgstation/commit/67ba177982213799984a70e89536c5efb3d17e14) This is a decently nice effect imo, it allows us to bump their power (read, alpha) since it'll get animated away. I try to sync the animation to the actual icon state's flow (it's 0.7s long). I also sped them up somewhat to hopefully have a nicer looking effect? we'll see. [Abstracts away intercepting overlay lights into a holder datum](https://github.com/tgstation/tgstation/pull/95362/commits/b3f1fe74f2c3bab1d8912ab8a666bd05677ad032) This should make it far easier to reuse this pattern! [Fixes overlay lights flashing to double intensity when picked up off the ground](https://github.com/tgstation/tgstation/pull/95362/commits/1d83f2031fa2b33312b2aea4359c0c37c9d04ac7) We needed to clear out their underlays BEFORE the animation [Adds a flickering effect to flares and their children](https://github.com/tgstation/tgstation/pull/95362/commits/b7a858e04a607c58b6c7fbe1476ffe2239e63bde) I'm still not 100% happy with this, I was trying to avoid it feeling like a heartbeat with random noise and I.. THINK it worked? it's honestly quite hard to tell [Adds the same flickering to lighters, welding tools and life candles](https://github.com/tgstation/tgstation/pull/95362/commits/3ec44027e17835ae96702cec5f0b12d1f4deb32b) Also, updated light candles to mirror the appearance of normal candles and use overlay lighting EDIT: I realized while working on flares that I accidentally double applied color, so if you saw the sparks animations before now it was different (less vibrant). IDK if I like this better or worse but it is RIGHT and that's what matters. ## Why It's Good For The Game I got mad about how bad these looked, and this is a start at improving them. Also, adds a framework for more dynamic effects applied to overlay lights (you could use this to apply a sort of "emergency rotating" effect, or flicker/buzz for example). <details> <summary>Before</summary> https://github.com/user-attachments/assets/66437f27-ee3c-4f14-a7ee-4a1c3e68533a https://github.com/user-attachments/assets/ed14fff8-a7eb-47fe-bab5-9a490ac96629 </details> <details> <summary>After</summary> https://github.com/user-attachments/assets/fb24ff2e-c745-42a5-8e11-c8a1eeef35a5 https://github.com/user-attachments/assets/fd8c2116-cb92-4fe6-ad3e-786a6538e52a </details> ## Changelog 🆑 add: Reworks how sparks render. They're now a bit brighter, will fade out as they move/if they hit something, will stack with each other less and also won't start hang in the air on spawn. add: Added a flickering effect to lighters, welding tools, flares, torches and candles (since they're flames). fix: Overlay based lights (think flashlights) will no longer flash to double intensity while being picked up. refactor: Reworked how some effects (explosion particles, sparks, some reagent stuff) function, report any bugs! /🆑 |
||
|
MrMelbert
|
750ca9d2ec | Two as anything greps (and some other cleanup) (#92974) | ||
|
Tim
|
dce0bf9f9a |
Correct bitwise logic for bitfield checks (#92609)
## About The Pull Request This fixes several bitfield operations that were missing parenthesis encapsulation. I noticed this problem in: - #92601 And decided to use regex to search for similar patterns which I came across in: - Move loops bypassing the `MOVELOOP_STATUS_RUNNING` status - Elastic arms mutation bypassing `ABSTRACT` object flags for picking up objects - Species radiation bypassing `HEAD_HAIR` hairstyle flags for balding - Damaged APC board status bypassing `EMAGGED` and `BROKEN` status for screentips - Shuttle cleanup code bypassing `MOVE_CONTENTS` for moving old turfs - Tram crossing signals bypassing `NORTH` and `EAST` direction checks ## Why It's Good For The Game Code behaves as intended. |
||
|
Watermelon914
|
6c017cf1e1 |
Refactors subsystems to use dependency-ordering to determine init order. Subsystems can now declare their own dependencies. (#90268)
## About The Pull Request
As the title says.
`init_order` is no more, subsystems ordering now depends on their
declared dependencies.
Subsystems can now declare which other subsystems need to init before
them using a list and the subsystem's typepath
I.e.
```dm
dependencies = list(
/datum/controller/subsystem/atoms,
/datum/controller/subsystem/mapping
)
```
The reverse can also be done, if a subsystem must initialize after your
own:
```dm
dependents = list(
/datum/controller/subsystem/atoms
)
```
Cyclical dependencies are not allowed and will throw an error on
initialization if one is found.
There's also a debug tool to visualize the dependency graph, although
it's a bit basic:
Subsystem load ordering can still be controlled using `init_stage`, some
subsystems use this in cases where they must initialize first or last
regardless of dependencies. An error will be thrown if a subsystem has
an `init_stage` before one of their dependencies.
## Why It's Good For The Game
Makes dealing with subsystem dependencies easier, and reduces the chance
of making a dependency error when needing to shift around subsystem
inits.
## Changelog
🆑
refactor: Refactored subsystem initialization
/🆑
|
||
|
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 /🆑 |
||
|
SmArtKar
|
f317c5796b |
[NO GBP] Hotfix for CI flaky due to the spacemove fix (#88408)
## About The Pull Request We don't check if the loop is actually queued as we attempt to remove, fire and queue it, which makes our loop potentially run in parallel with a higher priority loop, which (for some reason specifically on during engiborg tests and specifically on wawa) was causing a flaky CI failure. Closes #88400 ## Changelog 🆑 /🆑 |
||
|
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. /🆑 |
||
|
jimmyl
|
6b77ce5416 |
moves the movement subsystem off background (#87247)
## About The Pull Request movement subsystem now has the SS_BACKGROUND flag removed excuse me if this isnt any correct like i know daedalus did this for some reason at best ## Why It's Good For The Game (stuff controlled by) movement ss is not actually THAT costly (compared to Throwing)  (when i nuked metastation on local) and i think being able to move when you slip on oil or whatever eg jetpacks during lotsa lag is pretty important this does not actually make it immune to lag it just seems to mitigate the issue by a slight margin ## Changelog 🆑 code: Movement Subsystem no longer is a background subsystem. This means that you should no longer get stuck after slipping on oil during instances of high usage. /🆑 |
||
|
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.  **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. /🆑 |
||
|
norsvenska
|
5f80128fa9 |
Corrects 200+ instances of "it's" where it should've been "its" instead (#85169)
## About The Pull Request it's - conjunction of "it" and "is" its - possessive form of "it" grammar is hard, and there were a lot of places where "it's" was used where it shouldn't have been. i went and painstakingly searched the entire repository for these instances, spending a few hours on it. i completely ignored the changelog archive, and i may have missed some outliers. most player-facing ones should be corrected, though ## Why It's Good For The Game proper grammar is good ## Changelog 🆑 spellcheck: Numerous instances of "it's" have been properly replaced with "its" /🆑 |
||
|
Mothblocks
|
bc4e7d3b4e | Remove data systems in favor of global datums (#82943) | ||
|
Jeremiah
|
c1a775efe1 |
Implements data systems (#82816)
## About The Pull Request Subsystems currently come in two different flavors: 1. Systems that process at intervals with the master controller 2. Global data containers that do not fire And I think they should be split up... This moves 4 non firing, non init subsytems -> datasystem ## Why It's Good For The Game Clarity in code |
||
|
Bloop
|
73d8721951 |
Fixes some runtimes in pathfinding (and bonus) (#80735)
## About The Pull Request Found these while running a test server all night. I am not sure if the second one really causes issues because `.` is being set to something but it is is certainly polluting the runtime logs. Also fixes an unrelated runtime with one of the admin verbs, where it would runtime if you canceled out of the input prompt. ## Why It's Good For The Game Less runtime spam.   ## Changelog 🆑 fix: fixes some runtimes in pathfinding code, as well as one in the give direct control admin verb /🆑 |
||
|
Ben10Omintrix
|
13e27c36a6 |
basic bot path huds and medbot research (#80277)
## About The Pull Request this pr integrates the bot path huds to ai controllers and move loops to allow basic bots to display their paths in the hud. also closes #80280 and closes #80330 ## Why It's Good For The Game basic bots now can display their path on huds ## Changelog 🆑 add: basic bots can now display their paths on huds fix: medbots can research healing again /🆑 |
||
|
LemonInTheDark
|
3223d2a3fb |
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> |
||
|
Profakos
|
1e8507e154 |
Initializes on_finish_callbacks in the JPS move loop (#79505)
## About The Pull Request The on_finish_callbacks list in `/datum/move_loop/has_target/jps` was not initialized. Usually, when you add something to an uninitialized list, it gets initialized and the item gets added to it. However, the `CALLBACK` wrapper is around `new /datum/callback`, this fails. This meant on_finish_callback was not a list, therefore at the end of pathfinding, its contents could not be iterated and invoked. This PR fixes this problem by initializing the list. ## Why It's Good For The Game Closes #79383 Blob minions rally and punch again. ## Changelog 🆑 fix: Basic mobs using JPS can move again /🆑 |
||
|
LemonInTheDark
|
2532911353 |
Adds pathmaps, refactors pathfinding a bit (#78684)
## About The Pull Request Implements /datum/pathfind/sssp, which generates /datum/path_map /datum/path_maps allow us to very efficently generate paths to any turf they contain from their central point. We're effectively running the single source shortest paths algorithm. We expand from the center turf, adding turfs as they're found, and then processing them in order of addition. As we go, we remember what turf "found" us first. Reversing this chain gives us the shortest possible path from the center turf to any turf in its range (or the inverse). This isn't all that useful on its own, outside of a few niche cases (Like if we wanted to get the farthest reachable turf from the center) but if we could reuse the map more then once, we'd be able to swarm to/from a point very easily. Reuse is a bit troublesome, reqiures a timeout system and a way to compare different movables trying to get paths. I've implemented it tho. I've refactored CanAStarPass to take a datum, /datum/can_pass_info. This is built from a movable and a list of access, and copies all the properties that would impact pathfinding over onto itself. There is one case where we don't do this, pathing over openspace requires checking if we'd fall through the openspace, and the proc for that takes an atom. So instead we use the weakref to the owner that we hold onto, and hold copies of all the values that would impact the check on the datum. When someone requests a swarmed path their pass info is compared with the pass info of all other path_maps centered on their target turf. If it matches and their requested timeout isn't too short, we just reuse the map. Timeout is a tricky thing because the longer a map exists the more out of date it gets. I've added a few age defines that let you modulate your level of risk here. We default to only allowing maps that are currently being generated, or finished generating in our tick. Hopefully this prevents falling into trouble, but consumers will need to allow "failed" movements. As a part of this datumized pass info, I've refactored pathfinding to use access lists, rather then id cards directly. This also avoids some dumbass harddel oppertunities, and prevents an idcard from changing mid path. Did a few things to the zPass procs, they took args that they did NOT need, and I thought it'd be better to yeet em. If you'd all like I could undo the caching/can_pass_info stuff if you'd all like. I think it's useful generally because it avoids stuff changing mid pathfind attempt, but if it's too clunky I could nuke it. Oh also I added optional args to jps that constricts how it handles diagonals. I've used this to fix bot paths. ## Why It's Good For The Game Much of this is redundant currently. I'm adding it because it could have saved hugglebippers, and because I get the feeling it'll be useful for "grouping" mobs like bees and such. We're doing more basic mob work currently and I want to provide extra tools for that work. https://github.com/tgstation/tgstation/assets/58055496/66aca1f9-c6e7-4173-9c38-c40516d6d853 ## Changelog 🆑 add: Adds swarmed pathfinding, trading accuracy for potential optimization of used correctly fix: Bots will no longer take diagonal paths, preventing weirdo looking path visuals refactor: Refactored bits of pathfinding code, hopefully easier to add new pathfinding strategies now /🆑 |
||
|
Jacquerel
|
517d33e6f0 |
Basic blob mobs (#78520)
## About The Pull Request I remembered today that blob code is ass, especially blob spores. There's still a lot to improve but I cleaned up _some_ of it by converting these mobs. Now they use a newer framework and more signal handling as compared to circular references. I _expect_ the behaviour here to largely be the same as it was or similar. I haven't added anything fancy or new. This is a reasonably big PR but at least all of the files are small? Everything here touched every other thing enough that it didnt make sense to split up sorry. Other things I did in code: - Experimented with replacing the `mob/blob` subtype with a component. Don't know if this is genius or stupid. - AI subtree which just walks somewhere. We've used this behaviour a lot but never given it its own subtree. - Blob Spores and Zombies are two different mobs now instead of being one mob which just changes every single one of its properties. - Made a few living defence procs call super, because the only thing super does was send a signal and we weren't doing that for no reason. Also added a couple extra signals for intercepts we did not have. ## Changelog 🆑 fix: Blob spores will respond to rallies more reliably (it won't runtime every time they try and pathfind). fix: Blobbernaut pain animation overlays should align with the direction the mob is facing instead of always facing South refactor: Blob spores, zombies, and blobbernauts now all use the basic mob framework. They should work the same, but please report any issues. /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: san7890 <the@san7890.com> |
||
|
Bloop
|
4c870f71ca |
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 /🆑 |
||
|
Time-Green
|
ec9434ea6b |
Adds cliffs to icebox (#77062)
## About The Pull Request Adds cliffs to the game! They're tiles usable for mapping to make mountainy area's and cliffs! I don't have any sprites for them yet, so just imagine it's a cliff really hard  THESE DO NOT REPLACE MULTI-Z AND NEVER WILL! They're just a neat way to add more depth to the game. You can’t really add 10 different z’s for one mountain, so this can be used to help map area’s with depth without overusing z-levels They've been mapped into the top part of the icebox outside. There's not a good way to do sides of cliffs yet (will need some thinking), so they're mapped in such a fashion where it doesn't matter much. Later, this area above icebox can be expanded with properly done side-cliffs, something like in stardew-valley would work for our grid-system:  Longer demonstration: https://www.youtube.com/watch?v=Eig4jXNZZRQ Eventually, I'll redo mapgen and add 3x3 icebox (definitely not coping) ## Why It's Good For The Game The incredible flatness of icebox drives me insane. While multi-z is great at giving it more depth, the actual terrain itself is still completely flat. Adding cliffs let's us add 'soft-mountains', which does wonders for making an area feel more alive (And I absolutely adore snowy mountains) ## Changelog 🆑 add: Adds cliffs to the north of icebox. Try not to fall of of them! /🆑 <details> <summary>Additional images (now outdated)</summary> https://github.com/tgstation/tgstation/assets/7501474/572dc749-596c-4cab-9693-43c2270aca96     </details> --------- Co-authored-by: Jacquerel <hnevard@gmail.com> |
||
|
Ghom
|
d9677e39be |
Converting crabs to basic mobs (#77109)
## About The Pull Request Exactly what it reads on the tin. As a bonus, they will flee from attacking targets, hunt tiny critters (crabs are now small-sized) and actually move sideways (it's an element that covers both client and basic movement) ## Why It's Good For The Game Another simple to basic mob refactor. ## Changelog 🆑 refactor: Crabs refactored into basic mobs. They now hunt tiny critters and flee from attackers. fix: Fixed crabs not crab-walking. /🆑 |
||
|
LemonInTheDark
|
ae5a4f955d |
Pulls apart the vestiges of components still hanging onto signals (#75914)
## About The Pull Request Signals were initially only usable with component listeners, which while no longer the case has lead to outdated documentation, names, and a similar location in code. This pr pulls the two apart. Partially because mso thinks we should, but also because they really aren't directly linked anymore, and having them in this midstate just confuses people. [Renames comp_lookup to listen_lookup, since that's what it does](https://github.com/tgstation/tgstation/commit/102b79694fa8eb57ecf7b36032616a9e368ccced) [Moves signal procs over to their own file](https://github.com/tgstation/tgstation/commit/33d07d01fd336726b4f6f6f1b61bb0b3f11a00dc) [Renames the PREQDELETING and QDELETING comsigs to drop the parent bit since they can hook to more then just comps now](https://github.com/tgstation/tgstation/commit/335ea4ad081ec63c42cfa05856e582cca833af6e) [Does something similar to the attackby comsigs (PARENT -> ATOM)](https://github.com/tgstation/tgstation/commit/210e57051df63f88dac3dd83321236da825aae5e) [And finally passes over the examine signals](https://github.com/tgstation/tgstation/commit/65917658fb8a1e7d28ae23c9437a583d646f0302) ## Why It's Good For The Game Code makes more sense, things are better teased apart, s just good imo ## Changelog 🆑 refactor: Pulled apart the last vestiges of names/docs directly linking signals to components /🆑 |
||
|
Ghom
|
7bc5e03ae5 |
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> |
||
|
Ghom
|
e1344a5ddc |
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. /🆑 |
||
|
LemonInTheDark
|
b64a76ea56 |
Fixes moveloop shit (#75675)
## About The Pull Request I was using the step_x procs when I should have been using get_step_x and Move() This was causing some mob behavior to not properly respect things like gravity or potentially entered/exited signals. Also ensures we pass direction into Move consistently, and deletes a function that was meant to like, use step_to but with directions? Was never actually used properly I forgot to properly respect the "don't change dir" flag Closes #75673 🆑 fix: Mobs will fly around space... less /🆑 |
||
|
san7890
|
43473a4dac |
Turns Deer into Basic Mob - They Freeze At The Sight of Vehicles (#74784)
## About The Pull Request deers only show up in the BEPIS but i decided that they would be easy enough to turn into a basic mob (they were). it was so easy in fact that i decided to dip my toes into coding AI behavior, and made them freeze up whenever they see a vehicle. this required a lot of code in a bunch of places that i was quite unfamiliar with before starting this project, so do let me know if i glonked up anywhere and i can work on smoothing it out. ## Why It's Good For The Game one less simple animal on the list. deers staring at headlights is pretty cool i think, neato interaction for when you do get them beyond the joke the bepis makes i'm also amenable to dropping the whole "deer in headlights" code if you don't like that for w/e reason- just wanted to make them basic at the very least ## Changelog 🆑 add: If you ever happen upon a wild deer, try not to ride your fancy vehicles too close to it as it'll freeze up like a... you know where I'm going with this. /🆑 --------- Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
CapybaraExtravagante
|
bd81d32080 |
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> |
||
|
Time-Green
|
bf73344399 |
[READY] DRAMATIC SHUTTLES!! You can now fly around the shuttle (#71906)
You can move around shuttles during transport now! Instead of them teleporting you instantly into deepspace, you can move around somewhat depending on your space-mobility and grip-strength.  **Please watch the demonstration aswell, it should answer most questions:** https://www.youtube.com/watch?v=Os77qDOVSXE Interactions: - Being within armsreach of a wall or solid object means you 'cling', where the shuttle pull is very weak and you can basically run around the shutt;e (but dont fuck up or you're gone) - Being in range of nothing gives you a very heavy pull, you can barely resist if you have a decent jetpack - Objects are instantly power-yeeted - Being pulled or riding something excempts you from hyperspace pull - Touching a space tile while being on hyperspace dumps you in deepspace, you either go back to the shuttle or enjoy deepspace - On shuttle hyperspace tiles are a lot less dangerous, and will instead launch and freeze you instead of teleporting you into deepspace - In-case it wasn't obvious, you can rest outside the shuttle as long as something is blocking your path. I think it's funny but I might nerf it 🆑 add: You can now fly around the shuttle during transit! Woohoo! You can either cling to the side or grab a jetpack and try and keep up with the shuttle! Carps can move around freely in hyperspace qol: Increased shuttle hyperspace size from 8 tiles to 16 /🆑 - [x] Find a way to detect when a shuttle arrives and do something with the shit left in hyperspace Things I will do in another PR: - Engines spit fire and hurt (almost finished but I want to keep this small) - Random shuttle events. You might run into dust meteors or migrating carps OR A CHANGELING INFILTRATOR - Hyperspace turfs on the shuttle pull you under the shuttle ### Why it's good for the game It's so much more immersive than being instantly teleported into deepspace. It gives you a chance to recover if you get spaced or for daredevils to look cool It's also just very cool idk |
||
|
AnturK
|
4d6a8bc537 |
515 Compatibility (#71161)
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>
|
||
|
Tastyfish
|
4733643f39 |
Clean up subsystem Initialize(), require an explicit result returned, give a formal way to fail (for SSlua) (#69775)
* cleanup SS API, give SSlua a proper way to error out * New SS_INIT_ system |
||
|
Seth Scherer
|
f1a363c825 |
Converts a shitload of istypes to their more concise macros (#69260)
* Converts a lot of istypes() to use their istype macro helpers. |
||
|
MNarath
|
e44df2bf9e |
ports moveloop comparison from bee(and fixes goliaths not chasing people) (#67145)
This is a port of my PR from the beestation downstream BeeStation/BeeStation-Hornet#6845. This basically adds a proc that will check if the arguments forwarded to generate the new moveloop are identical with the ones on maybe an old loop before it allows it to overwrite it that way we won't endlessly make new loops and destroy old ones even trough there is no reason to. closes #64510 (Goliaths don't move after you shoot them) Now the reason why this fixes goliaths chasing others is because goliaths have a movement delay of like 4 seconds enough time for the proc adding the moveloop to chase the target to fire again and add a new moveloop with the same arguments basically overwriting the old moveloop before that one could move the goliath even once this then basically resets the timer for the goliath to move and this goes on pretty much forever the only times the goliath can move is if lag somehow allows the moveloop to move the parent atom before it can get overwritten again (very rare but happened like once during testing). Now my PR simply stops new identical moveloops (identical in terms of arguments) to get created and to overwrite old moveloops and thus allows the moveloop to continue normally and actually fire for goliaths. stops unnecessary moveloop datums from beeing created and also fixes a bug as a bonus |
||
|
LemonInTheDark
|
7e9ff85f2a |
[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 |
||
|
LemonInTheDark
|
dfa6977f6e |
Enables out of order moveloop removal (#66532)
Two things going on here. First, a stupid clerical error I made in the dequeue_loop proc that prevented loops from removing themselves from a queue. This was easy to resolve. Second and more complex. pour_bucket makes this assumption that when it's done with a bucket, it can just pop the first one that's sitting in the queue. This is unfortunately not always true, because the bucket can be already cleared by a dequeue_loop called under loop.process(). The fix for this is to do some sanity checking on the index and bucket_time arguments. It's not perfect, but a second assoc lookup and a length check isn't that bad. The alternative would be merging buckets and sorted_buckets into one list, but that requires doing quite a few text2num calls on insertion, which I am not a fan of. Thank you to DamianX and MNarath1 for mentioning this issue, and discussing it with me You guys are real cool |
||
|
LemonInTheDark
|
079f8ac515 |
Adds moveloop bucketing, uses queues for the singulo rather then sleeps (#64418)
Adds a basic bucketing system to move loops. This should hopefully save a lot of cpu time, and allow for more load while gaining better smoothness. The idea is very similar to SStimer, but my implementation is much more simple, since I have to worry less about long delays and redundant buckets. Insertion needs to be cheaper too, since I'm making a system that by design holds a lot of looping things It comes with some minor tradeoffs, we can't have constant rechecking of loops if a move "fails", not that we really want that anyway We also lose direct control over the timer var, but I think that's better, don't want people manipulating that directly Not that it even really worked very well back when we did have it Removes the sleep from singularity code Rather then using sleep to store the state of our iteration, we instead queue the iteration in a list. We then use a custom singulo processing subsystem to call our "digest" proc several times per full eat, with the hope of staying on top of our queue This rarely happens because the queue is too large, god why is a sm powered singulo 24x24 tiles. I've also A: cached our dist checks, and B: Added dist checks to prevent attempting to pull things out of range This might look a bit worse, but it saves a lot of work Oh right and I made the singulo unable to eat while it still has tiles to digest. The hope is to prevent overwork and list explosion. Hopefully this will prevent singulo server stoppage, though I've seen some other worrying things in testing. |
||
|
LemonInTheDark
|
934a5ea498 |
Actually fixes strange mob delays: BEEPSKY IS TOO FAST edition (#64351)
* Revert " Properly speeds up a lot of things, mostly mobs (#64270)"
This reverts commit
|
||
|
LemonInTheDark
|
a836574388 |
Properly speeds up a lot of things, mostly mobs (#64270)
When I made my move loop changes (
|
||
|
LemonInTheDark
|
fb0403a4d8 |
Disposal/Move loop fixes (#64236)
Fixes misc moveloop runtimes souced by mid move deletes and disposal loop traps, this was caused by a misunderstood bit of logic. current_pipe needs to be set to the actual return value of transfer() rather then our current location |
||
|
LemonInTheDark
|
da20556050 |
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 |
||
|
LemonInTheDark
|
815bb8ae40 |
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> |
