mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-17 11:05:16 +01:00
docker-container
40 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
21b4095dfd |
[MDB IGNORE] [IDB IGNORE] Upstream Sync - 04/17/2026 (#5453)
Upstream 04/17/2026 fixes https://github.com/Bubberstation/Bubberstation/issues/5549 --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: tgstation-ci[bot] <179393467+tgstation-ci[bot]@users.noreply.github.com> Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: Rhials <28870487+Rhials@users.noreply.github.com> Co-authored-by: rageguy505 <54517726+rageguy505@users.noreply.github.com> Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com> Co-authored-by: Aliceee2ch <160794176+Aliceee2ch@users.noreply.github.com> Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> Co-authored-by: Tsar-Salat <62388554+Tsar-Salat@users.noreply.github.com> Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> Co-authored-by: Maxipat <108554989+Maxipat112@users.noreply.github.com> Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> Co-authored-by: deltanedas <39013340+deltanedas@users.noreply.github.com> Co-authored-by: SimplyLogan <47579821+loganuk@users.noreply.github.com> Co-authored-by: loganuk <fakeemail123@aol.com> Co-authored-by: Leland Kemble <70413276+lelandkemble@users.noreply.github.com> Co-authored-by: FalloutFalcon <86381784+FalloutFalcon@users.noreply.github.com> Co-authored-by: Roxy <75404941+TealSeer@users.noreply.github.com> Co-authored-by: Lucy <lucy@absolucy.moe> Co-authored-by: siliconOpossum <138069572+siliconOpossum@users.noreply.github.com> Co-authored-by: Isratosh <Isratosh@hotmail.com> Co-authored-by: TheRyeGuyWhoWillNowDie <70169560+TheRyeGuyWhoWillNowDie@users.noreply.github.com> Co-authored-by: Neocloudy <88008002+Neocloudy@users.noreply.github.com> Co-authored-by: Alexander V. <volas@ya.ru> Co-authored-by: ElGitificador <168473461+ElGitificador@users.noreply.github.com> Co-authored-by: Twaticus <46540570+Twaticus@users.noreply.github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> Co-authored-by: Cameron Lennox <killer65311@gmail.com> Co-authored-by: Tim <timothymtorres@gmail.com> Co-authored-by: Iamgoofball <iamgoofball@gmail.com> Co-authored-by: Layzu666 <121319428+Layzu666@users.noreply.github.com> Co-authored-by: Arturlang <24881678+Arturlang@users.noreply.github.com> Co-authored-by: _0Steven <42909981+00-Steven@users.noreply.github.com> Co-authored-by: mrmanlikesbt <99309552+mrmanlikesbt@users.noreply.github.com> Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com> Co-authored-by: John F. Kennedy <54908920+MacaroniCritter@users.noreply.github.com> Co-authored-by: Cursor <102828457+theselfish@users.noreply.github.com> Co-authored-by: Josh <josh.adam.powell@gmail.com> Co-authored-by: Josh Powell <josh.powell@softwire.com> Co-authored-by: Yobrocharlie <Charliemiller5617@gmail.com> Co-authored-by: Hardly3D <66234359+Hardly3D@users.noreply.github.com> Co-authored-by: shayoki <96078776+shayoki@users.noreply.github.com> Co-authored-by: LT3 <83487515+lessthnthree@users.noreply.github.com> |
||
|
|
7a994fffba |
Pathfinder Module no longer pathfinds (#94261)
## About The Pull Request  Removes the "pathfinding through the halls" function of the MODsuit pathfinder module in favour of having it "fly" to your location in the same manner as cargo pods (by getting inside an invisible cargo pod). If it's inside a locked crate or locker when this happens it will break the door on the way out, so be careful where you leave it. ## Why It's Good For The Game Mostly because nobody uses the pathfinder module. Pathfinding through the corridors is _cool_ on a conceptual level but it's not very practical, _especially_ because it means that it has a good chance of not functioning at all if you are on a station with Z levels. This method means that it will always arrive in the same amount of time (quite fast, but not fast enough that it will arrive before someone can shoot you) regardless of where you are when you suddenly realise that you need spaceproofing rather than drip. Also Fikou asked me to do it. ## Changelog 🆑 balance: The Captain's MODSuit pathfinder module now flies it directly to their location rather than physically traversing the halls of the station. /🆑 |
||
|
|
db9e3cf9dd |
red raptors are now able to attack while ridden (#92455)
## About The Pull Request red raptors will now be able to retaliate against mobs adjacent to it while ridden. ## Why It's Good For The Game red raptors dont have much use compared to its colleagues. this gives it a bit of a unique purpose and makes it a viable option to have out on the field ## Changelog 🆑 balance: red raptors are now able to attack while ridden /🆑 |
||
|
|
173185ea9a |
[no gbp] few repairbot fixes and some beacon pathing improvements. (#88144)
## About The Pull Request this fixes some few sentient repairbot-related issues that were reported a few days ago. ive also given sentient repairbots a new simple UI to manage their materials.  while I was at it, i also fixed bots continuously trying to path to unreachable beacons, which can be quite costly since they're regularly very far away. ## Why It's Good For The Game closes #88067 ## Changelog 🆑 fix: repairbots no longer get flashed by their own welder fix: repairbots no longer break glass tables they step on fix: repairbots can no longer flush their own welders fix: fixes some runtimes when emagged repairbots try to deconstruct things fix: fixes sentient repairbots not being able to see or remove their material counts /🆑 |
||
|
|
72491a5e41 |
Fix monkeys ignoring grabs while restrained/in crit (#88041)
## About The Pull Request Fixes #84338 When handcuffed or crit, you are unable to resist even a passive grab, you are truly helpless Yet monkeys ignore this They ignore this because the code handling above is on the client: `/client/proc/Process_Grab()` The ideal fix for this is to move it off the client, but that carries a bunch of order of operations shenanigans so I'll leave that for a more in depth refactor of this kinda stuff In the meanwhile we can simply tell AI controllers not to move if grabbed and incapacitated (barring stasis) ## Changelog 🆑 Melbert fix: Monkeys no longer ignore basic rules such as "you can't escape a passive grab if you're cuffed or in crit" /🆑 |
||
|
|
d2c8e10e26 |
Repairbots (#86084)
## About The Pull Request adds repairbots to the game!  this pr serves as a massive rework and buff to floorbots. i was a bit sad that they dont get built much anymore so ive given them tons of more utilities and uses. Repairbots still inherit to place tiles and repair breaches. but they can now rebuild walls, rebuild windows and repair structure and machinery. Also Ive given them voicelines to add more character to them. In short, they are very depressed with their job (however they express their happy go lucky attitude when u emag them where they will start deconstructing the station) to demonstrate capabilities, here's a slightly sped up clip of some repairbots patching up an area that was maxcapped 4 times: https://github.com/user-attachments/assets/bddac3b0-1984-4571-85d3-c5283dd7c0de When repairbots feel threatened, they will retract into their little toolbox which u can pick up and hold in ur hand, either to conveniently carry and plop them down at breached sites, or to bash skull with it U can build them using a toolbox, proximity sensor, cyborg arm and a conveyor belt ## Why It's Good For The Game refactors floorbots and makes them alot more useful tools for engineers to use ## Changelog 🆑 refactor: floorbots have been refactored, please report any bugs add: adds repairbots to the game! /🆑 |
||
|
|
239797a4ee |
Deletes misleading infinite define, adds defines for clearer status effect durations (#87842)
## About The Pull Request 1. Deletes `INFINTIE`, it is misleading and not at all a big number and causes bugs 2. Adds `STATUS_EFFECT_PERMANENT` and `STATUS_EFFECT_NO_TICK` to make it clearer what infinite status effects are |
||
|
|
51cc8d62dc |
fixes botkeeper displaying wrong states (#86786)
## About The Pull Request bot modes werent correctly reflecting the bot's AI states. this pr fixes that. also fixes some issues where the bot's AI might get stuck inbetween switching modes ## Why It's Good For The Game closes #86771 ## Changelog 🆑 fix: botkeeper now displays bot's correct states! /🆑 |
||
|
|
91baa94ac5 |
event based incapicated and able_to_run (#86031)
## About The Pull Request this is a revival of #82635 . i got permission from potato to reopen this, he did almost all the work. i only just solved the conflicts and fixed all the bugs that were preventing the original from being merged (but it should be TMed first) ## Why It's Good For The Game slightly improves the performance of basic mob AI ## Changelog 🆑 LemonInTheDark refactor: able_to_run and incapacitated have been refactored to be event based /🆑 --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> Co-authored-by: ZephyrTFA <matthew@tfaluc.com> |
||
|
|
d2c7806047 |
Spelling and Grammar Fixes (#85992)
## About The Pull Request Fixes several errors to spelling, grammar, and punctuation. ## Why It's Good For The Game ## Changelog 🆑 spellcheck: fixed a few typos /🆑 |
||
|
|
6934b13ee2 |
Adds a TRAIT_NO_TRANSFORM check to AI movement. (#83621)
## About The Pull Request Checks for `TRAIT_NO_TRANSFORM` in `allowed_to_move`. Will stop mobs from moving when they should not. ## Why It's Good For The Game Fixes #79870 Fixes AI movement not respecting TRAIT_NO_TRANSFORM. ## Changelog 🆑 Goat fix: mobs no longer move during cutscenes /🆑 |
||
|
|
55c41fb9ad |
basic honkbots (#81920)
## About The Pull Request this refactors honkbots into basic mobs. its mostly a faithful 1:1 refactor but i couldnt keep my hands to myselves so i gave them some new behaviors. honkbots now love playing with clowns, they will go seek out for clowns and celebrate around them. also, if the honkbot finds a banana peel or a slippery item near it, it will actively drag people onto them honkbots will now go out of theirway to mess with secbots and annoy them ## Why It's Good For The Game refactors hinkbots into basic bots and also undoes some of the silliness i did in the previous basic bot prs. i also added lazylist support to remove_thing_from_list. ## Changelog 🆑 refactor: honkbots are now basic mobs, please report any bugs add: honkbots will try to slip people on banana peels /🆑 |
||
|
|
bc4e7d3b4e | Remove data systems in favor of global datums (#82943) | ||
|
|
e8787ed2b7 |
fixes jps mobs occasioanlly pathing forever (#82874)
## About The Pull Request if MOVELOOP_NOT_READY gets passed once through the signal (which can be often), the failure increments gets reset back to 0 and starts counting again. this can cause the increments to never reach the max failure threshold so itll keep checking forever. i saw some mobs get stuck trying to reach an unreachable target because of this ## Why It's Good For The Game fixes mobs getting stuck trying to reach something unreachable ## Changelog 🆑 fix: fixes mobs getting stuck trying to reach something unreachable /🆑 |
||
|
|
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 |
||
|
|
77399e2083 |
Fix modsuit pathfinder module / JPS changes (#81983)
## About The Pull Request The Pathfinder module sucks cock because it doesn't work. And the reasons it doesn't work are as follows: 1. It uses the default JPS pathfinding datum, which has a hard distance limit of 30, instead of the intended 200. 2. JPS pathfinding as a whole will fail if you encounter more than 3 doors. This is because every door wastes about 5 movement opportunities, and the default pathfinder only has a limit of 20 before it considers the entire pathfinding attempt moot and bails out. Here's how I fixed it: 1. Created a new jps child that has a range of MOD_AI_RANGE 2. Instead of counting all failures during the entire pathfinding attempt, it will only consider consecutive failures. Every successful move will reset the pathfinding failure count. This should make JPS pathfinding more reliable overall? ## Changelog 🆑 fix: Modsuit Pathfinder module is significantly better at finding it's destination. /🆑 |
||
|
|
dd5234b401 |
[no gbp] fixes ai controller runtime (#81134)
## About The Pull Request fixes the flaky error that would happen in cleanbot controllers. i discovered thru the profiler that a proc i was using to stop tracking unreachable targets and caching them to a blacklist in selectbehavior had a bit of a high real time cost, so if the mob got deleted midway through for any reason would cause a runtime error. ive moved this proc off selectbehavior and im instead letting the move loop cache this target into the blacklist if it reaches the max pathing attempts ## Why It's Good For The Game fixes a runtime that sometimes happens in ai controllers ## Changelog 🆑 fix: fixes a runtime that sometimes happens in ai controllers /🆑 |
||
|
|
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 /🆑 |
||
|
|
a3c24dd74e |
Basic bots (medibots) (#79955)
## About The Pull Request refactors bots into basic bots. i decided to do medibots first because they were the most complex bots and wanted to get them out of the way first. if this pr gets merged then i will be rolling out the rest of the bot refactors over the next months medibots can now wear any type of hats! some of these hats can trigger unique new recorded voicelines and interactions!   ## Why It's Good For The Game converts medbots into basic medbots. they are now a bit more responsive than before but overall they should act similarly to how they did. also adds the basic bot ai framework which has all the generic bot behaviors that the next bots may or may not need to have in their ai. i tried my best to improve their code and turned some of their bitflags into define bitfields. this pr may need a careful review because i did it from scratch as the old bot project branch was too outdated for me to use ## Changelog 🆑 refactor: medbots are now basic bots. please report any bugs add: medbots can wear hats! /🆑 |
||
|
|
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> |
||
|
|
51220a36c1 |
Basic mobs check for MOBILITY_MOVE to move (#79627)
## About The Pull Request Adds a check for `MOBILITY_MOVE` in basic mob `allowed_to_move`. This prevents AI controlled mobs which are `TRAIT_IMMOBILIZED` from, well, not being immobilized ## Changelog 🆑 Melbert fix: AI controlled mobs which are immobilized are now properly immobilized /🆑 |
||
|
|
162e3aac66 |
Improves how ai movement checks for if movement is allowed (#79620)
## About The Pull Request While looking into the moveloop processing issues I found a place where moveloops were being interacted with while qdeleted. This restructures the code a bit to prevent that being possible and also improves the design overall here so implementers of `allowed_to_move` don't need to be careful about their return value, which is just begging for a bug down the line. `increment_pathing_failure` also wasn't getting called when subtypes stopped movement. The rest of this description is a bit of an informative lecture. There's a pattern you do on occasion when designing public facing functions where you have a public, but non overridden, function with some default behavior that must always run, calling on an internal function that *is* overridden but never called from any other location. This is a good pattern for making sure some core behavior always runs or for making sanity checks that can't be dodged, as the internal function never even gets called when it has been determined that something needs to cancel the whole thing. Previously this code had something that looked kinda like this, there was a proc called `pre_move` that was not supposed to be overridden, and a proc it called called `allowed_to_move`. However, contrary to the usual reason for doing this, `pre_move` had no behavior itself and was meaningless. `allowed_to_move` on the other hand had exactly the sort of sanity check that we'd want using this pattern in the form of `if(!controller.able_to_run())`. This was allowing subtypes access to a qdeleted move loop when it had just been deleted in the parent's version of the proc. This is your yearly reminder to watch out for cargo culting. |
||
|
|
7c98a22628 |
Mobs will not path into dangerous turfs. (#79428)
## About The Pull Request Fixes #79255 Fixes #79272 Fixes #79313 Fixes #79328 As it turns out, "basic avoidance" and "dumb" AI pathfinding were both broken with regards to dangerous turfs, as was "random walk" idle behavior. Now, these three things will properly avoid turfs that could kill the mob. The global typecache of dangerous turfs has been removed, in favor of a turf-level proc, `can_cross_safely`, which returns TRUE or FALSE based on whether a movable atom can cross the turf without being harmed. This obviously defaults to TRUE, and is overridden for the four dangerous turf types: - **Space** can be safely crossed only with TRAIT_SPACEWALK. While space does not directly cause harm, being sent drifting away is not desirable behavior. - **Chasms** and **open space** can be safely crossed with TRAIT_MOVE_FLYING. - **Lava** can be safely crossed with TRAIT_MOVE_FLYING or TRAIT_LAVA_IMMUNE. If an AI's pathfinding would take it through a dangerous turf, or if it tries to randomly step onto one, the movement will be cancelled. ## Why It's Good For The Game Basic mobs have all been ignoring dangerous terrain this whole time. This means that mobs on Lavaland could walk right into chasms, mobs on multi-Z stations could be tricked into falling into pits, and so on. In the case of idle movement, no checks were happening whatsoever, causing similar problems without players ever being involved. Notably, skeleton mobs on certain away missions were randomly wandering into lava, causing one of our many random CI failures of the last week. They won't do that anymore. All told, this should make AI behavior a little more believable, by giving basic mobs literally any sense whatsoever of self-preservation. ## Changelog 🆑 fix: Basic mobs will no longer randomly walk into terrain that harms or kills them. /🆑 --------- Co-authored-by: Jacquerel <hnevard@gmail.com> |
||
|
|
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 /🆑 |
||
|
|
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> |
||
|
|
72174845f5 |
Basic Watchers & Basilisks (#77630)
## About The Pull Request This one is a double feature because Watchers and Basilisks share the same typepath. You might see a couple more of those. As is tradition I decided to fuck with them rather than just port them. Here's what's up. **Basilisks**   - Have a new soulless sprite which looks less like a living blue hedge. - Walk at you and shoot you while you are not in range (just like before). - Become supercharged if they become "heated" by lava, lasers, or temperature weapons. This was a feature they also previously had but they would never encounter lava, so now it also works if you use the wrong gun on them. - Lose their supercharge if you cool them down. - Otherwise pretty normal mobs. **Watchers** https://www.youtube.com/watch?v=kOq_Bf78k5A Here's a traditional video of me intentionally getting hit by mechanics (trust me its definitely on purpose) - They glow emmissively a little bit so you can see them from further away. - Their eyes light up about 0.5 seconds before they are able to shoot at you. - No longer melee attack, instead try to stay out of melee. - Will occasionally put you into "Overwatch", meaning they will shoot you rapidly if you move or act while they're staring at you for a brief time period (after which you become immune for 12 seconds, and during which other watchers will play fair and stop shooting at you). - If they start taking damage they will also start using their "Gaze" attack, look away or suffer some kind of negative effect! - - Normal watcher gaze flashes and confuses you. - - Magmawing watcher gaze obviously burns (and briefly stuns) you. - - Icewing watcher gaze freezes you and throws you backwards. - Magnetically attract and eat diamonds. They also used to do this, but just if they happened to coincidentally walk past some. **Other accompanying changes** All basic mobs will now adopt the "stop gliding" trait if they get slowed down too much. I moved behaviour for "fire a projectile from this atom" into a helper proc because I was using it in three places and I will probably use it in more places. There are probably other places in the existing code which could be using this. I think I made the basic mob melee attack forecast default a little more forgiving, they were fucking me up too much and I am the playtester. ## Why It's Good For The Game Another one off the list. New tricks for old dogs. Framework for making mobs with ranged attacks "fairer" (you can see when they are ready to shoot you). More (hopefully) versatile AI behaviours which we will reuse later (I hope I'm not duplicating one someone already made). If our players "enjoy" them enough we can give more mobs "don't look at me" mechanics. Removes some soul sprites. ## Changelog 🆑 refactor: Basilisks and Watchers now use the basic mob framework. Please bug report any unusual behaviour. sprite: Basilisks have new sprites. add: Basilisks will go into a frenzy if heated by energy weapons or temperature beams as well as by lava. add: Watcher eyes will be illuminated briefly when they are ready to fire at you. add: Watchers can now briefly put you into "Overwatch" and penalise you for moving while they can see you. add: Wounded watchers will occasionally punish players who look at them. balance: Unusual watcher variants are more likely to appear. /🆑 |
||
|
|
ed2f04f486 |
Experiment with replacing weakrefs in AI blackboard with deleting signals, ideally making it easier to work with and harder to cause hard deletes (#74791)
## About The Pull Request Replaces weakref usage in AI blackboards with deleting signals All blackboard var setting must go through setters rather than directly ## Why It's Good For The Game This both makes it a ton easier to develop AI for, and also makes it harder for hard deletes to sneak in, as has been seen with recent 515 prs showing hard deletes in AI blackboards (To quantify "making it easier to develop AI", I found multiple bugs in existing AI code due to the usage of weakrefs.) I'm looking for `@Jacquerel` `@tralezab` 's opinions on the matter, also maybe `@LemonInTheDark` if they're interested ## Changelog 🆑 Melbert refactor: Mob ai refactored once again /🆑 |
||
|
|
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> |
||
|
|
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> |
||
|
|
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>
|
||
|
|
70db96c46f |
Convert mouse and rat to basic mobs (#70728)
* Converts mice and rats to basic mobs * Update paths * Fixes * Tweaks * . * Use helpers * Unit test * Correct the targeting * Fixes the unit test? * Fixes the unit test * Docs * update the path script with pr id * Faction check tweak * Review * AHH |
||
|
|
fcaa0b24db |
Alphabetized, fixed spelling error, clarifying event descriptions. Polish (#69707)
About The Pull Request Alphabetized several long lists of strings so its easier for us to look through them, just code polish, nothing the players would see. Fixed some minor spelling errors as well. Clarified door bolt state to be less ambiguous in the door wiring gui. Originally it would say the door bolts have fallen, and the door bolts "Look up". i dont know about you but that was very not clear for me to read. Like where are the bolts? In the door or the frame? Arnt there bolts on top and bottom? Just didn't make sense to me. Now it says "Have engaged!" & "Have disengaged" hopefully that makes the state clearer at a glance. I also added a small handful of funny texts to some string files. See changelog Why It's Good For The Game Well, who doesn't like a bit of polish? Just makes the game a little easier for people. Also funny text funny text. Changelog spelling: improves spelling and adds more flavortext |
||
|
|
da36517f7c |
Removes some boilerplate code from basic AI (#64826)
* Squashed commit of the following: commit |
||
|
|
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> |
||
|
|
b3f5ab3c30 |
prevents ai from moving after being killed (#63455)
I don't like that they move, when you kill them |
||
|
|
46cb925af0 |
Basic Mobs: the cooler simple mobs that run on datum AI. (With reworked cockroach AI as proof of concept) (#60694)
Simple_animals / mobs are the biggest lie in this code-base. They're far from simple and have an extreme god-object problem. Especially when you get to /hostile, where there is so many procs, vars, and what not, that you can't make any interesting additions without snowflaking the hell out of the code. This PR hopes to help kill this problem by introducing a new /living subtype, /living/basic. The idea of this refactor is to slowly start moving all old simple_animals to this new system, moving over behaviors like charging and more extravagant mobs like megafauna over bit by bit similar to how newfood was implemented. One of the other big goals of this refactor is to move many of the fringe simple animal behaviors into either AI datums, or components/elements. (Some of which still needs to be done in this PR). As a proof of concept, I created the base mob/living/basic, and moved cockroaches over to the system. Since cockroaches have both a passive, melee and ranged mob. This PR does slightly affect balance as the behavior isn't 1-on-1 due to it no longer running on the janky /hostile behavior, but I tried to keep the effects to a minimum, and the glockroach and hauberoach are not spawnable through many means as far as I know. |
||
|
|
7b5e83e1e9 |
Revives PR #58579; Sligh refactor to AI datums that allows for basic support of subtrees (#60249)
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> Co-authored-by: coiax <yellowbounder@gmail.com> Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com> Co-authored-by: Rohesie <rohesie@gmail.com> Co-authored-by: Matthew J. <12817816+ZephyrTFA@users.noreply.github.com> Co-authored-by: AnturK <AnturK@users.noreply.github.com> Co-authored-by: Jonathan Rubenstein <jrubcop@gmail.com> Co-authored-by: Kylerace <kylerlumpkin1@gmail.com> Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com> Co-authored-by: tralezab <40974010+tralezab@users.noreply.github.com> Co-authored-by: Jordan Brown <Cyberboss@users.noreply.github.com> Co-authored-by: Fikou <piotrbryla@onet.pl> Co-authored-by: Emmanuel S. <emmanuelssr@gmail.com> |
||
|
|
ced28d5cec |
Dog AI 2.0 (#57186)
Now that JPS and AI movement datums are fully merged, I'm here to take another (my third actually) crack at giving dogs fun AI. Here's a video demonstration (somewhat WIP), and a quick rundown of everything dogs will be able to do. Basically all of these behaviors are generic and can be extended to other simple mobs, Commands and Friendship Fetching Attack/Harass Heel Play Dead |
||
|
|
dc78e93543 |
Adds tourist robots that order food and drinks from the bar and cafeteria (#57010)
* Adds Tourism Economy Co-authored-by: Emmanuel S. <emmanuelssr@gmail.com> Co-authored-by: ATH1909 <42606352+ATH1909@users.noreply.github.com> Co-authored-by: coiax <yellowbounder@gmail.com> Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
|
bb8faec7a1 |
Adds a subsystem for ai movement (#57111)
* done * straight walk * movement * yep * removes unused macro * done * Update ai_movement.dm |