mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-01-18 21:15:21 +00:00
403274ff62d14466c0057d4bfeeec1fa1bb19f27
26 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
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]( |
||
oranges
|
4c48966ff8 |
Renames delta time to be a more obvious name (#74654)
This tracks the seconds per tick of a subsystem, however note that it is not completely accurate, as subsystems can be delayed, however it's useful to have this number as a multiplier or ratio, so that if in future someone changes the subsystem wait time code correctly adjusts how fast it applies effects regexes used git grep --files-with-matches --name-only 'DT_PROB' | xargs -l sed -i 's/DT_PROB/SPT_PROB/g' git grep --files-with-matches --name-only 'delta_time' | xargs -l sed -i 's/delta_time/seconds_per_tick/g' |
||
tralezab
|
c0ef4ba907 |
Adds the Dark Matt-eor when you emag a stupid amount of meteor shields + lots of meteor file sorting + qol + dark matter singularity + dark matt-eor summoning final traitor objective (#74330)
## About The Pull Request <details> <summary>Dark Matt-eor Image</summary>  </details> > A barely visible blur in the cosmic darkness, like a ghostly shadow on a moonless night. A piercing howl in the vacuum of space, as if it were tearing the fabric of reality. A twisted halo of light around it, bending and breaking the rays of distant suns. A shower of quantum sparks, flickering and fading in its wake. A dark matter meteor (dark matt-eor) is a wonder to witness, and to dread. > A sudden impact, like a hammer blow to the heart of the station. A violent tremor, shaking and shattering the metal walls and windows. A deafening roar, as the air rushes out of the breached hull. A blinding flash, as the dark matter meteor unleashes its hidden energy. A tiny black hole, forming and growing in the center of the station. A relentless pull, dragging everything towards the abyss. A dark matter meteor is incredibly deadly. Emagging too many meteor shields will summon a dark matt-eor. This comes with several warnings, and after awhile, warns the station that someone is trying to summon a dark matteor. The dark matt-eor itself is not that damaging in its impact, but drops a singularity in its final resting place. ## Why It's Good For The Game It's a new way to terrorize a round as an antagonist. Before, emagging a lot of meteor shields would basically make meteor showers the only event that can run, which is cool, but since constant meteor waves are going to destroy the station, let's also throw in the mother of all meteors! This also adds warnings to spamming emagging meteor shields, which imo needs it. The round ends when someone spams emagged meteor shields, and since they're meteor shields nobody is going to reasonably check on them. ## Changelog 🆑 add: The dark matt-eor add: Summon a dark matt-eor final traitor objective add: Dark matter singularity variant, which can't grow as big as a regular singularity but hungers for blood code: cleaned up/sorted meteor shield code, satellite control, and more qol: added a lot of feedback to interacting with meteor shields balance: emagging a lot of meteor shields warns the station, but emagging enough of them summons a Dark Matt-eor. /🆑 |
||
Rhials
|
32bd462458 | Changeling Meteor event now breaks more gracefully and will absolutely make sure the changeling gets where it should (#73433) | ||
Jacquerel
|
cfb2d9feb9 |
Meteor events won't try and run on icebox (#73241)
## About The Pull Request While I was trying to improve changeling meteor spawning on Icebox I noticed that several other meteor-like events don't seem to be blocked on Icebox either even though they don't do anything. I added a new capability to events which can prevent them being loaded under certain map conditions (specifically: whether the map is in space or not). Currently there's no events which _only_ run on a planet but, now someone could add one I guess? Now all of the events which spawn meteors are filtered out on icebox and you can't absent-mindedly try to trigger them.  Also a couple of dynamic options had this applied too, chiefly ones which expect you to be able to fly a space ship to the space station. ## Why It's Good For The Game These events shouldn't run on Icebox (or soon, Chilled) because they don't do anything there. AFAICT Meteors were getting as far as trying to spawn, then would retry trying to find space tiles which didn't exist until they failed 10 times, then give up. Once per every meteor it tried to spawn. Gross. ## Changelog 🆑 fix: Meteors can't be triggered automatically or manually on Icebox, where they do nothing. fix: Hacking a comms console as a traitor won't try to summon meteors or pirates to Icebox, where they do nothing. /🆑 |
||
Jeremiah
|
872e64fb05 |
Adds spaces around logical operators (#72603)
## About The Pull Request Part of a prior PR that was closed (#72562). This version does not add the check in CI. ## Why It's Good For The Game The work is already done, so I figured why not. ## Changelog N/A Nothing player facing Co-authored-by: Jeremiah Snow <jlsnow301@pm.me> Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
Jacquerel
|
b174af7661 |
Basic Mob Carp Part VIII: Basic Mob Carp (#72073)
## About The Pull Request Wow we're finally here. This turns carp into Basic Mobs instead of Simple Animals. They use a variety of behaviours added in previous PRs to act in a marginally more interesting way than they used to. But don't worry there's still 2 or 3 PRs to follow this one until I'm done with space fish. Changes in this PR: Carp will try to run away if they get below 50% health, to make use of their "regenerate if not attacked" component. Magicarp have different targetting behaviour for spells depending on their spell; - Ressurecting Carp will try to ressurect allied mobs. - Animating Carp will try to animate nearby objects. - Door-creating Carp will try to turn nearby walls into doors. You can order Magicarp to cast their spell on something if you happen to manage to tame one. The eating element now has support for "getting hurt" when you eat something. Carp eating can rings and hating it was too soulful not to continue supporting. ## Why It's Good For The Game Carp are iconic beasts and I think they should be more interesting. Also we just want to turn mobs into basic mobs anyway. ## Changelog 🆑 add: Carp will now run away if their health gets low, meaning they may have a chance to regenerate. add: Lia will now fight back if attacked instead of letting herself get killed, watch out! balance: Magicarp will now aim their spells more intelligently. add: Tame Magicarp can be ordered to use their spells on things. refactor: Carp are now "Basic Mobs" instead of "Simple Mobs" fix: Dehydrated carp no longer give you a bad feeling when they're your friend and a good feeling when they're going to attack you. balance: Tamed carp are now friendly only to their tamer rather than their whole faction, which should make dehydrated carp more active. Order them to stay or follow you if you want them to behave around your friends. /🆑 |
||
|
Rhials
|
47ec8ecd38 |
Adds the Sandstorm random event, directional meteor functionality, space sand. (#71802)
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may not be viewable. --> <!-- You can view Contributing.MD for a detailed description of the pull request process. --> ## About The Pull Request  Hey guys, it's your boy. Back at it again with another meteor-adjacent event PR. Adds the Sandstorm random event, inspired by the long-unused admin only one. It picks a direction to approach from, alerts the crew of its imminent arrival, and after a little over a minute of preparatory time, sends waves of sand and dust to grind down everything in that direction. To accomplish this, some minor adjustments had to be made to meteor generation code. They can now be passed an optional arg for a direction to be thrown from, and will pick a random one if no direction is given. Also introduces the newest addition to our cast of meteors -- space sand! It's even weaker than space dust, and shows up exclusively in this event. Space sand is **ineffective against rwalls**, and will not damage the arrivals area's high-tech sand-resistant glass. This is to prevent this event from venting one of the most dust-vulnerable areas on the station, and to make sure new players aren't shafted into firelock hell when the right angle is picked. I did a lot of testing and tweaking of numbers to get the damage to average at about the level I'm comfortable with. This is meant to be a high-impact event that isn't as destructive (or unavoidable) as a meteor wave. Speaking of avoidance, let's talk about mitigation: You get an early warning and a direction the sand will come from. You have time to grab repair supplies, move to safety, get a MODsuit. You can make worthwhile repairs as the sand comes in from inside (or outside, if you're brave enough) with nothing more than a welder and iron sheets. If you're feeling particularly spicy, you can leverage your prep time setting up shield generators, which spawn in engineering and have been added to the maintenance machines loot pool. Anyone can contribute, so do your part as a good crewmate and help out! All that being said, the event can't be prevented entirely. Shit's going to get shredded, especially on the outside of the station. Damage will vary heavily based on the station and direction, ranging from inconsequential to threatening. It should happen late enough into the round that, at the bare minimum, the crew shouldn't be caught unprepared. For those of you who are worried, the ORIGINAL sandstorm admin event is still with us too. It's been moved from the space dust file into the Sandstorm event file. This PR also makes a very minor change to the naming of the space _dust_ events, for better menuing. So, to sum it all up: Sand hits grinds down one side of the station, you get a minute of warning, shield generators now spawn in maintenance. Be a good crewmate and help where you can. <!-- Describe The Pull Request. Please be sure every change is documented or this can delay review and even discourage maintainers from merging your PR! --> ## Why It's Good For The Game More event variety is good, and events that give the players agency on how bad the impact will be is even better. <!-- Argue for the merits of your changes and how they benefit the game, especially if they are controversial and/or far reaching. If you can't actually explain WHY what you are doing will improve the game, then it probably isn't good for the game in the first place. --> ## Changelog <!-- If your PR modifies aspects of the game that can be concretely observed by players or admins you should add a changelog. If your change does NOT meet this description, remove this section. Be sure to properly mark your PRs to prevent unnecessary GBP loss. You can read up on GBP and it's effects on PRs in the tgstation guides for contributors. Please note that maintainers freely reserve the right to remove and add tags should they deem it appropriate. You can attempt to finagle the system all you want, but it's best to shoot for clear communication right off the bat. --> 🆑 Rhials add: Sandstorm random event! A random side of the station is pummeled by an onslaught of sand and dust. If you hear that one is approaching, grab a welder and some iron to help with repairs! add: Space sand! It's weak and doesn't hurt reinforced walls, but shouldn't be underestimated in high quantities. code: You can now pass a start direction to the spawn_meteors/spawn_meteor global procs. /🆑 <!-- Both 🆑's are required for the changelog to work! You can put your name to the right of the first 🆑 if you want to overwrite your GitHub username as author ingame. --> <!-- You can use multiple of the same prefix (they're only used for the icon ingame) and delete the unneeded ones. Despite some of the tags, changelogs should generally represent how a player might be affected by the changes rather than a summary of the PR's contents. --> |
||
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>
|
||
Twaticus
|
c7dde06668 |
[MDB Ignore]Hats DMI split (#70060)
Splits head dmi into separate files for both mob and obj icons. Kept similar to suit split categorization + some more. New files include beanie, bio, chaplain, costume, cowboy, default, hats(softcaps, fedoras, head caps, generic hats), helmet(helmets and other armored headgear/hoods), spacehelm, utility(hardhats, mostly work related hats), wizard. Moves animal/pet head sitting icons to 1 folder, pets_head.dmi Renames PAI head sitting icon file to pai_head.dmi |
||
|
Rhials
|
8166ff2278 |
Removes some bad code from the bananium meteor (#69649)
Removes some unnecessary, guideline violating code from the bananium meteor. WHOOPIES. No GBP on this one, its a fresh fuckup on my part. Why It's Good For The Game Bolsters code maintainability by 3%. Changelog cl code: Removes erroneous code from bananium meteor. This should not affect players in any way. /cl |
||
|
Rhials
|
43a5e42feb |
Stray Meteor event, five new special meteors, and another reason to build meteor shields (#69550)
Adds the Stray Meteor random event, as well as a few new special meteors to be featured in it (as well as to meteor waves, but to a lesser degree). Other than these special meteors being a part of meteor waves, the meteor wave event itself is unchanged by this new event. A single meteor is thrown somewhere in the vicinity of the station, accompanied by a brief warning announcement. To make things more interesting, five new special meteor types have been created to accompany the original three (flaming/irradiated/tunguska). The special meteors have been added to the meteor wave pools, but have lesser weight than the standard meteors. Enough about that though... |
||
Kylerace
|
fe7513d282 | addresses reviews on the tram pr made after merge, fixes diagonal movement bugs (#68033) | ||
|
Kylerace
|
8f0df7816b |
(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 (#66657)
ever see the tram take 10 milliseconds per movement to move 2100 objects? now you have https://user-images.githubusercontent.com/15794172/166198184-8bab93bd-f584-4269-9ed1-6aee746f8f3c.mp4 About The Pull Request fixes #66887 done for the code bounty posted by @MMMiracles to optimize the tram so that it can be sped up. the tram is now twice as fast, firing every tick instead of every 2 ticks. and is now around 10x cheaper to move. also adds support for multiz trams, as in trams that span multiple z levels. the tram on master takes around 10-15 milliseconds per movement with nothing on it other than its starting contents. why is this? because the tram is the canary in the coal mines when it comes to movement code, which is normally expensive as fuck. the tram does way more work than it needs to, and even finds new ways to slow the game down. I'll walk you through a few of the dumber things the tram currently does and how i fixed them. the tram, at absolute minimum, has to move 55 separate industrial_lift platforms once per movement. this means that the tram has to unregister its entered/exited signals 55 times when "the tram" as a singular object is only entering 5 new turfs and exiting 5 old turfs every movement, this means that each of the 55 platforms calculates their own destination turfs and checks their contents every movement. The biggest single optimization in this pr was that I made the tram into a single 5x11 multitile object and made it only do entering/exiting checks on the 5 new and 5 old turfs in each movement. way too many of the default tram contents are expensive to move for something that has to move a lot. fun fact, did you know that the walls on the tram have opacity? do you know what opacity does for movables? it makes them recalculate static lighting every time they move. did you know that the tram, this entire time, was taking JUST as much time spamming SSlighting updates as it was spending time in SStramprocess? well it is! now it doesnt do that, the walls are transparent. also, every window and every grille on the tram had the atmos_sensitive element applied to them which then added connect_loc to them, causing them to update signals every movement. that is also dumb and i got rid of that with snowflake overrides. Now we must take care to not add things that sneakily register to Moved() or the moved signal to the roundstart tram, because that is dumb, and the relative utility of simulating objects that should normally shatter due to heat and conduct heat from the atmosphere is far less than the cost of moving them, for this one object. all tram contents physically Entered() and Exited() their destination and old turfs every movement, even though because they are on a tram they literally do not interact with the turf, the tram does. also, any objects that use connect_loc or connect_loc behalf that are on the same point on the tram also interact with each other because of this. now all contents of the tram act as if theyre being abstract_move()'d to their destination so that (almost) nothing thats in the destination turf or the exit turf can react to the event of "something laying on the tram is moving over you". the rare things that DO need to know what is physically entering or exiting their turf regardless of whether theyre interacting with the ground can register to the abstract entered and exited signals which are now always sent. many of the things hooked into Moved(), whether it be overrides of Moved() itself, or handlers for the moved signal, add up to a LOT of processing time. especially for humans. now ive gotten rid of a lot of it, mostly for the tram but also for normal movement. i made footsteps (a significant portion of human movement cost) not do any work if the human themselves didnt do the movement. i optimized has_gravity() a fair amount, and then realized that since everything on the tram isnt changing momentum, i didnt actually need to check gravity for the purposes of drifting (newtonian_move() was taking a significant portion of the cost of movement at some points along the development process). so now it simply doesnt call newtonian_move() for movements that dont represent a change in momentum (by default all movements do). also i put effort into 1. better organizing tram/lift code so that most of it is inside of a dedicated modules folder instead of scattered around 5 generic folders and 2. moved a lot of behavior from lift platforms themselves into their lift_master_datum since ideally the platforms would just handle moving themselves, while any behavior involving the entire lift such as "move to destination" and "blow up" would be handled by the lift_master_datum. also https://user-images.githubusercontent.com/15794172/166220129-ff2ea344-442f-4e3e-94f0-ec58ab438563.mp4 multiz tram (this just adds the capability to map it like this, no tram does this) Actual Performance Differences to benchmark this, i added a world.Profile(PROFILER_START) and world.Profile(PROFILER_START) to the tram moving, so that it generates a profiler output of all tram movement without any unrelated procs being recorded (except for world.Profile() overhead). this made it a lot easier to quantify what was slowing down both the tram and movement in general. and i did 3 types of tests on both master and my branch. also i should note that i sped up the "master" tram test to move once per tick as well, simply because the normal movement speed seems unbearably slow now. so all recorded videos are done at twice the speed of the real tram on master. this doesnt affect the main thing i was trying to measure: cost for each movement. the first test was the base tram, containing only my player mob and the movables starting on the tram roundstart. on master, this takes around 13 milliseconds or so on my computer (which is pretty close to what it takes on the servers), on this branch, it takes between 0.9-1.3 milliseconds. ALSO in these benchmarks youll see that tram/proc/travel() will vary significantly between the master and optimized branches. this is 100% because there are 55 times more platforms moving on master compared to the master branch, and thus 55x more calls to this proc. every test was recorded with the exact same amount of distance moved here are the master and optimized benchmark text files: master master base tram.txt https://user-images.githubusercontent.com/15794172/166210149-f118683d-6f6d-4dfb-b9e4-14f17b26aad8.mp4 also this shows the increased SSlighting usage resulting from the tram on master spamming updates, which doesnt happen on the optimized branch optimized optimization base tram.txt https://user-images.githubusercontent.com/15794172/166206280-cd849aaa-ed3b-4e2f-b741-b8a5726091a9.mp4 the second test is meant to benchmark the best case scaling cost of moving objects, where nothing extra is registered to movement besides the bare minimum stuff on the /atom/movable level. Each of the open tiles of the tram had 1 bluespace rped filled with parts dumped onto it, to the point that the tram in total was moving 2100 objects. the vast majority of these objects did nothing special in movement so they serve as a good base case. only slightly off due to the rped's registering to movement. on master, this test takes over 100 milliseconds per movement master 2000 obj's.txt https://user-images.githubusercontent.com/15794172/166210560-f4de620d-7dc6-4dbd-8b61-4a48149af707.mp4 when optimized, about 10 milliseconds per movement https://user-images.githubusercontent.com/15794172/166208654-bc10086b-bbfc-49fa-9987-d7558109cc1d.mp4 optimization 2000 obj's.txt the third test is 300 humans spawned onto the tram, meant to test all the shit added on to movement cost for humans/carbons. in retrospect this test is actually way too biased in favor of my optimizations since the humans are all in only 3 tiles, so all 100 humans on a tile are reacting to the other 99 humans movements, which wouldnt be as bad if they were distributed across 20 tiles like in the second test. so dont read into this one too hard. on master, this test takes 200 milliseconds master 300 catgirls.txt when optimized, this takes about 13-14 milliseconds. optimization 300 catgirls on ram ranch.txt Why It's Good For The Game the tram is literally 10x cheaper to move. and the code is better organized. currently on master the tram is as fast as running speed, meaning it has no real relative utility compared to just running the tracks (except for the added safety of not having to risk being ran over by the tram). now the tram of which we have an entire map based around can be used to its full potential. also, has some fixes to things on the tram reacting to movement. for example on master if you are standing on a tram tile that contains a banana and the TRAM moves, you will slip if the banana was in that spot before you (not if you were there first however). this is because the banana has no concept of relative movement, you and it are in the same reference frame but the banana, which failed highschool physics, believes you to have moved onto it and thus subjected you to the humiliation of an unjust slipping. now since tram contents that dont register to abstract entered/exited cannot know about other tram contents on the same tile during a movement, this cannot happen. also, you no longer make footstep sounds when the tram moves you over a floor TODO mainly opened it now so i can create a stopping point and attend to my other now staling prs, we're at a state of functionality far enough to start testmerging it anyways. add a better way for admins to be notified of the tram overloading the server if someone purposefully stuffs it with as much shit as they can, and for admins to clear said shit. automatically slow down the tram if SStramprocess takes over like, 10 milliseconds complete. the tram still cant really check tick and yield without introducing logic holes, so making sure it doesnt take half of the tick every tick is important go over my code to catch dumb shit i forgot about, there always is for these kinds of refactors because im very messy remove the area based forced_gravity optimization its not worth figuring out why it doesnt work fix the inevitable merge conflict with master lol create an icon for the tram_tunnel area type i made so that objects on the tram dont have to enter and exit areas twice in a cross-station traversal add an easy way to vv tram lethality for mobs/things being hit by it. its an easy target in another thing i already wanted to do: a reinforced concept of shared variables from any particular tram platform and the entire tram itself. admins should be able to slow down the tram by vv'ing one platform and have it apply to the entire tram for example. Changelog cl balance: the tram is now twice as fast, pray it doesnt get any faster (it cant without raising world fps) performance: the tram is now about 10 times cheaper to move for the server add: mappers can now create trams with multiple z levels code: industrial_lift's now have more of their behavior pertaining to "the entire lift" being handled by their lift_master_datum as opposed to belonging to a random platform on the lift. /cl |
||
Kapu1178
|
6d470992cb |
This tail refactor turned into an organ refactor. Funny how that works. (#67017)
* Fuck you (refactors ur tails) * Errors * Wow. Pain. * Fixes up probably everything * finish up here * Fixes hard del maybe * original owner hard del * garbage collection runtime * suck my peen byond * Mapped tails * motherfucker. * motherrfucker. again. * Whooopppppsie * yeah bad idea * Turns out external organs literally just sat in nullspace forever if their parent was deleted, and didnt Remove() themselves, causing harddels. * So anyways I repathed all organs * Fixes * really. * unit test... test * unit test-test but it passes linters this time because im a moh-ron * I've lost track of what im doing at this point * Hopefully fixes hard del? * meh * Update code/datums/dna.dm * things n stuff * repath from master pull |
||
|
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
|
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> |
||
TemporalOroboros
|
11ccf19741 |
Makes sure COMSIG_ATOM_EX_ACT is always called. (#63685)
Creates a wrapper macro for ex_act() and moves the signal and contents explosion calls to there. This way we can ensure the signal is always fired. Also desnowflakes reagents responding to explosions. Ensures that a signal is always called when the attendant proc is called. |
||
Mothblocks
|
271ce9f995 |
Move current pick_weight consumers to not pass in zeros (#62940)
About The Pull Request pick_weight_allow_zero was a backwards compatible hack, so it exists alongside pick_weight. I would really like to just remove the old proc and just rename it, so I want to log what, if anything, is relying on this behavior, to see if it's a bug or if it needs to be handled especially in that case. |
||
Ghom
|
b79dd74fd0 |
Replaces a portion of C-style for loops with the more commonplace for loops, which are faster. (#62624)
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com> |
||
|
Mothblocks
|
0f3c4e51f7 |
Modernizing Radiation -- TL;DR: Radiation is now a status effect healed by tox healing, and contamination is removed (#62265)
Implements the Modernizing radiation design document ( https://hackmd.io/@tgstation/rJNIyeBHt ) and replaces the current radiation sources with the new system, as well as replacing/removing a bunch of old consumers of radiation that either had no reason to exist, or could be replaced by something else. Diverges from the doc in that items radiation don't go up like explained. I was going to, but items get irradiated so easily that it just feels pretty lame. Items still get irradiated, but it's mostly just so that radiation sources look cooler (wow, lots of stuff around going green), and for things like the geiger counter. Instead of the complicated radiation_wave system, radiation now just checks everything between the radiation source and the potential target, losing power along the way based on the radiation insulation of whats in between. If this reaches too low a point (specified by radiation_pulse consumers), then the radiation will not pass. Otherwise, will roll a chance to irradiate. Uranium structures allow a delay before irradiating, so stay away! |
||
Ghilker
|
95c8e00af7 |
cleanup _HELPERS/_lists.dm and all the necessary files (#61827)
Bring _HELPERS/_lists.dm to latest standards by: -Adding proper documentation and fixing existing one -Giving vars proper names -Procs now use snake case as per standard (many files that use those procs will be affected) |
||
|
tralezab
|
6c01cc2c01 |
every case of initialize that should have mapload, does (#61623)
## About The Pull Request stop forgetting to include mapload, if you don't include it then every single subtype past it by default doesn't include it for example, `obj/item` didn't include mapload so every single item by default didn't fill in mapload  ## Regex used: procs without args, not even regex `/Initialize()` procs with args `\/Initialize\((?!mapload)((.)*\w)?` cleanup of things i didn't want to mapload: `\/datum\/(.)*\/Initialize\(mapload` |
||
Watermelon914
|
375a20e49b |
Refactors most spans into span procs (#59645)
Converts most spans into span procs. Mostly used regex for this and sorted out any compile time errors afterwards so there could be some bugs. Was initially going to do defines, but ninja said to make it into a proc, and if there's any overhead, they can easily be changed to defines. Makes it easier to control the formatting and prevents typos when creating spans as it'll runtime if you misspell instead of silently failing. Reduces the code you need to write when writing spans, as you don't need to close the span as that's automatically handled by the proc. (Note from Lemon: This should be converted to defines once we update the minimum version to 514. Didn't do it now because byond pain and such) |
||
|
TemporalOroboros
|
9f598a9662 |
Makes the explosive compressor and blastcannon actually use the TTVs they're given + the explosion changes to support that. (#58015)
* Adds explosion SFX to the blastcannon and explosive compressor - Extracts the explosion SFX and screenshake proc from the SSexplosions explosion handling proc and lets the explosive compressor and blastcannon use it. * Miscellaneous changes - Adds defines for the internal explosion arglist keys - Reverses the values of the explosion severity defines - Changes almost everything that uses `/proc/explosion` to use named arguments - Removes a whole bunch of argname = 0 in explosion calls. * Removes named callback arguments. * Changes the explosion signals to just use the arguments list Adds a simple framework to let objects respond to explosions occurring inside of them. Changes a whole bunch of explosions to use the object being exploded as the origin of the explosion rather than the turf the object is on. Makes the explosive compressor and blastcannon actually use the TTVs they are given. Adds support for things responding to internal explosions. Less snowflake code for the explosive compressor and blastcannon calculating bomb range.* Less confusing explosion severity defines. Less opaque explosion arguments *does not guarantee that the solution to letting them actually use the TTV is any less snowflake. |
||
|
Mothblocks
|
7e4de07506 |
Remove all gamemodes except Dynamic (#58470)
Removes all /datum/game_mode except dynamic. Eventually, all of mode and game_mode will be removed, and Dynamic will become an ingrained system. Every single other gamemode was unmaintained at best and poisoned other code at worst. Currently all tg servers run 24/7 Dynamic, so the time to act is now. * Remove gamemode references from age checks * Monkey * Remove heretics * Remove BBs * Refactor uplinks and remove clown ops * Remove nuke ops * Removes and refactors cult * Remove extended * Remove and move out meteors * Removes wizard * Remove sandbox * Remove changelings * Remove traitors * Remove revs * Remove gangs * Remove changing mode and voting for new gamemodes * get_candidates signature fix * Summon ERT and NERD in their own panel * Remove some old unneeded age_check stuff * Fix old signatures of get_uplink_items * Use Extended like config for dynamic.json * Fix discounted gear |
