mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-08-22 12:41:09 +01:00
StrangeWeirdKitten-patch-1
11
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
b69267ab8c |
Spacer's drift speed bonus doesn't stack with jetpack speed (#96169)
## About The Pull Request Splits `inertia_move_multiplier` in two, `inertia_move_multiplier_passive` and `inertia_move_multiplier_active` When calculating drift speed, only the better of the two is used.* Spacer now buffs the former, jetpacks now buff the latter In short, the bonus to drift speed applied from being a spacer no longer applies multiplicatively with the bonus to drift speed from jetpacks. **(If we want further nuance we'd probably have to look at something like movespeed modifiers. But in the meanwhile this aims to differentiate "this atom innately drifts faster" and "something is making this atom drift faster".)* ## Why It's Good For The Game The 0.75x modifier from Spacer combined with the 0.66x modifier jetpacks apply ultimately comes out to a bonus of like 0.5x, or in other words, a 2x speed bonus which is a liiiiiiiiiiittle ridiculous. Jetpack jousting is chaotic enough as-is. With the changes Spacers will still get mileage out of especially poor jetpacks (i.e. improvised jetpacks), but with a normal or advanced jetpack, they'll go as fast as anyone else does. ## Changelog 🆑 Melbert balance: Spacer: Bonus to drift speed no longer stacks with jetpack speed - only the greater of the two effects is applied. /🆑 |
||
|
|
442ad835bc |
Reverts inertia based space movement (#95536)
## About The Pull Request Reverts space movement being affected by inertia What is kept: - Items have a varying force on your drift speed, ie heavier items will move you faster through space, and smaller items, slower. - Jetpacks can have varying force of impulse - the effect is applied directly to the mob's `inertia_move_multiplier` - Tethers are unreverted - they still stop you from drifting too far from the tether point, however you can no longer 'swing' with them. What is removed: - Multiple impulses in the same angle/direction no longer speeds you up. Only the fastest impulse in 1 direction is accounted for. - An impulse in a different angle/direction will completely override any existing impulses, even if they are faster. - Jetpack stabilizers are once again perfectly capable of immediately stopping any active impulses. TL;DR If you point yourself in a direction you will now go that direction ## Why It's Good For The Game The concept was fun and had potential but the fight between impulses vs tiles was very, very clunky and janky. Multiple fixes were attempted to reduce the jank but it ultimately nograv still acts very cumbersome and jetpacks are still very unappealing to use. Smartkar gave the go-ahead to revert this a while back so, o7. ## Changelog 🆑 Melbert del: Zero-gravity drifting is no longer affected by inertia, ie it has been reverted to what it once was. /🆑 |
||
|
|
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! /🆑 |
||
|
|
80bd414237 |
Removes spacemove crashes/impacts at high speed (#92284)
## About The Pull Request Something changed in spacemove loop code recently which caused infinite recursions through throw code. This has been a rather bad mechanic already, and I believe that it warrants removal alongside newtonian zero-g physics in general - but for now lets just get rid of the part that crashes the server. ## Why It's Good For The Game We've pushed the speed limit to the point where you need to be firing a SAW without a jetpack for a full minute to actually crash into something, its a bad mechanic that doesn't bring much to the round as-is. |
||
|
|
8d48f8d4d2 |
Fixes an 8 year old bug which colored your HUDs with you (#88667)
## About The Pull Request Partially a port of https://github.com/DaedalusDock/daedalusdock/pull/1163 which is a port of my own code from bitbus Closes #88579 Instead of manually setting hud images and positioning we now can use set_hud_image_state which also updates their position to ensure that they scale with the owner atom. HUDs had RESET_COLOR and RESET_TRANSFORM but no KEEP_APART, so they were stuck with mobs all this time. I replaced RESET_TRANSFORM with PIXEL_SCALE (shouldn't be reserved to mob huds only to be honest) and added KEEP_APART, so that HUDs still scale/rotate with their owner but don't inherit their color. Also fixed the dragon issue, that's where this PR actually started. Closes https://github.com/tgstation/tgstation/issues/45411 ## Why It's Good For The Game I don't want my HUDs to be pretty pink when I make a barbie Clarke. ## Changelog 🆑 refactor: Rewrote some of HUD code so they're no longer colored in their owner's color fix: Space dragons no longer turn invisible when toggling seethrough mode /🆑 |
||
|
|
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 /🆑 |
||
|
|
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. /🆑 |
||
|
|
e41b5acf8e |
[NO GBP] Fixes lattices causing spacemove jank (#87320)
## About The Pull Request Lattices blocking space movement was handled on /atom/movable while my comsigs were on /mob, thus making lattices overrule all force code. Mobs now properly handle them via pushoff code. ## Why Is This Good For The Game Lattices are very jarring to move along rn, this was not intentional. ## Changelog 🆑 fix: Moving along lattices in space with a jetpack on no longer causes your screen to jerk /🆑 |
||
|
|
28bbca59b5 |
[NO GBP] Prevents walls from slowing your drifting down when you're moving in the same direction as your pressed movement key (#87142)
## About The Pull Request Oopsie, this prevents walls from slowing your drift down if you're pressing a movement key and moving in your intended direction ## Why It's Good For The Game Smoother movement when you're moving near a wall with a jetpack or tether or whatever really ## Changelog 🆑 qol: Jetpack movement near walls should be much smoother /🆑 |
||
|
|
3f0b4abb8d |
Replaces world.icon_size (and some magic numbers) with defines (#86819)
## About The Pull Request All usages of world.icon_size in code have been replaced with new `ICONSIZE_X`, `ICONSIZE_Y` and `ICONSIZE_ALL` defines depending on context Replaces some "32" magic numbers with the defines A few bits of code have been modified to split up x/y math as well ## Why It's Good For The Game Magic number bad, code more readable, code more flexible and I'm told there's an access cost to doing world.icon_size so minor performance gains ## Changelog 🆑 tonty code: made some code relating to the world's icon size more readable /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
|
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. /🆑 |