mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-17 11:05:16 +01:00
mayfools
261 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 MrMelbert
|
dd8af45715 |
Fix soup pots being unreachable (#93377)
## About The Pull Request Caused by #93165 I'm not sure but I think this was just missing a check for `TRAIT_SKIP_BASIC_REACH_CHECK`, because soup pots are given that trait ## Changelog 🆑 Melbert fix: You can interact with soup pots on stoves again /🆑 |
||
|
die
|
0204ab8fdd |
Canreach refactor (#93165)
## About The Pull Request ports https://github.com/DaedalusDock/daedalusdock/pull/1144 ports https://github.com/DaedalusDock/daedalusdock/pull/1147 full credit to @Kapu1178 for the juice instead of `reacher.CanReach(target)` we now do `target.CanBeReachedBy(reacher)`, this allows us to give special behavior to atoms which we want to reach, which is exactly what I need for a feature I'm working on. ## Why It's Good For The Game allows us to be more flexible with reachability ## Changelog 🆑 refactor: refactored how reaching items works, report any oddities with being unable to reach something you should be able to! /🆑 |
||
|
Arvid Gudbrand
|
46f3ebc5db |
Add bind (shift-alt-primary) specifically for opening the TGUI loot panel (#92813)
## About The Pull Request Adds a new bind `AltShiftClickOn` for explicitly opening the TGUI loot panel at some tile without raising any signals or calling into an override-able proc. This bind is in addition to the already existing alt-click and it is not intended to replace it. This is similar to [this pr](https://github.com/tgstation/tgstation/pull/92307) but does not replace the old bind nor add any features beyond the bind opening the loot panel. ## Why It's Good For The Game Originally I started looking into this because it was very obnoxious that I was able to interact with pipes placed in walls, but not pipes placed underneath windows. I had thought the issue was because the window overlapped the pipe and was unable to open the loot panel to get at it because the window handles alt-clicks through the `simple_rotation` component's signal handler. Unfortunately the pipe is still obscured by the window, so this does not fix that. However I still see this as useful as it allows opening the very nice and wonderful loot panel on a pile of items which may or may not handle the alt click signal without needing to hunt for a pixel of the tile (or of an item you _think_ may not handle it) to do so. ## Changelog 🆑 qol: shift+alt will open the tgui loot panel on any tile without being intercepted by items that may be on the tile code: adds a shift+alt click on proc for living mobs to explicitly open the tgui loot panel in addition to the already existing alt bind /🆑 |
||
|
Ghom
|
149de112f6 | Fixing two fishing issues. (#91444) | ||
|
_0Steven
|
752f048b04 |
You can now examine things through advanced camera consoles, holopad calls, and while looking up/down (#91175)
## About The Pull Request While playing around with stuff, I noticed an odd inconsistency in when we can and can't examine: Camera console/app? Yes. Advanced camera console? No. AI? Yes. Holopad call? No. In a locker? Yes. Looking up or down? No. Looking into it, I found it to come down to this line of code: https://github.com/tgstation/tgstation/blob/9234188a87d2715260008923094fc94db024cae3/code/_onclick/click.dm#L348 Where we check whether the user's eye is the user, the user's loc, or the `COMPONENT_ALLOW_EXAMINATE` flag. AIs have their own eye object, and so they work because of the `COMPONENT_ALLOW_EXAMINATE` flag getting set on the signal. Camera consoles work because your eye is still you, while you look through them. Lockers work because it also checks for your loc being your eye. Everything else on the previous list doesn't, because it moves your eye! Okay, well. Why? Why do those checks exist? This was last touched four months ago, in a pr letting AIs examine (#89146). This didn't change the logic. https://github.com/tgstation/tgstation/blob/89ead63f7dad55b525081cf978491e2aead1c939/code/_onclick/click.dm#L345 It was last changed meaningfully six years ago, in a dullahan examining fix pr (#48633). This added the `COMPONENT_ALLOW_EXAMINATE` part, without touching the eye parts. It doesn't mention why the eye parts exist. https://github.com/tgstation/tgstation/blob/c5b5d9613091b267be5437a3f7b9436046113069/code/_onclick/click.dm#L306 The next last change before it was ten years ago, in a commit mentioning locker examine fixes ( |
||
|
Ghom
|
339616ae78 |
You can now interact with held mobs beside wearing them (feat: "minor" melee attack chain cleanup) (#90080)
## About The Pull Request People can now pet held mothroaches and pugs if they want to, or use items on them, hopefully without causing many issues. After all, it only took about a couple dozen lines of code to make... ...Oh, did the 527 files changed or the 850~ lines added/removed perhaps catch your eye? Made you wonder if I accidentally pushed the wrong branch? or skewed something up big time? Well, nuh uh. I just happen to be fed up with the melee attack chain still using stringized params instead of an array/list. It was frankly revolting to see how I'd have had to otherwise call `list2params` for what I'm trying to accomplish here, and make this PR another tessera to the immense stupidity of our attack chain procs calling `params2list` over and over and over instead of just using that one call instance from `ClickOn` as an argument. It's 2025, honey, wake up! I also tried to replace some of those single letter vars/args but there are just way too many of them. ## Why It's Good For The Game Improving old code. And I want to be able to pet mobroaches while holding them too. ## Changelog 🆑 qol: You can now interact with held mobs in more ways beside wearing them. /🆑 |
||
|
TiviPlus
|
a0fa2dda57 |
Stub new undocumented 516 m4/m5 (#90404)
## About The Pull Request Lummox added these and didnt document them so these are leftclicking rn ## Changelog 🆑 fix: Mouse4 and Mouse5 no longer leftclick /🆑 Co-authored-by: TiviPlus <572233640+TiviPlus@users.noreply.com> |
||
|
John Willard
|
89ead63f7d |
AIs can now examine. (#89146)
## About The Pull Request AIs can now examine things that don't have a specific shiftclick interaction, which is solely APCs and airlocks. Also fixes Dullahans not being able to examine through their head, because that's a thing I found accidentally. ## Why It's Good For The Game AIs only being able to examine things near its core has always been very annoying, and you're currently able to examine things through security cameras anyways so it's not like we're consistent on how much details the cameras are able to see. This at least makes it a consistent "yes, you can examine through cameras". AIs also don't really have enough ShiftClick interactions to block all of examine just for their existence. ## Changelog 🆑 balance: AIs can now examine through their eye. fix: Dullahans can also examine through their head again. /🆑 --------- Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> |
||
|
tonty
|
3f0b4abb8d |
Replaces world.icon_size (and some magic numbers) with defines (#86819)
## About The Pull Request All usages of world.icon_size in code have been replaced with new `ICONSIZE_X`, `ICONSIZE_Y` and `ICONSIZE_ALL` defines depending on context Replaces some "32" magic numbers with the defines A few bits of code have been modified to split up x/y math as well ## Why It's Good For The Game Magic number bad, code more readable, code more flexible and I'm told there's an access cost to doing world.icon_size so minor performance gains ## Changelog 🆑 tonty code: made some code relating to the world's icon size more readable /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
Kylerace
|
8b4fd0c334 |
Revert "Refactor some usages of get_step_towards in loops to use get_steps_to instead" and subsequent fix (#86585)
## About The Pull Request
This reverts commit
|
||
|
Lucy
|
39e58f8b20 |
Refactor some usages of get_step_towards in loops to use get_steps_to instead (#86020)
## About The Pull Request BYOND 515 added a new proc called `get_steps_to` - which is basically `get_step_towards`, but instead it returns a list of directions! Ain't that nifty and useful? So we can just calculate the path once. Several helper procs - `can_see`, `CheckToolReach`, and `get_hearers_in_LOS`, use `get_step_towards` in a loop, so I've refactored them to just calculate the path once using `get_steps_to`, and then loop through the returned path of directions. ## Why It's Good For The Game In theory, should micro-optimize performance, by only calculating the pathfinding once. ## Changelog 🆑 refactor: Refactored some functions related to line-of-sight and reach to improve performance. /🆑 |
||
|
Ben10Omintrix
|
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> |
||
|
tgstation-ci[bot]
|
9a9b428b61 |
Wallening Revert [MDB Ignore][IDB Ignore] (#86161)
This PR is reverting the wallening by reverting everything up to
|
||
|
LemonInTheDark
|
4b4e9dff1d |
Wallening [IDB IGNORE] [MDB IGNORE] (#85491)
## What's going on here Kept you waitin huh! This pr resprites most all walls, windows and other "wall adjacent" things to a 3/4th perspective, technical term is "tall" walls (we are very smart). If you're trying to understand the technical details here, much of the "rendering tech" is built off the idea of split-vis. Basically, split a sprite up and render it on adjacent turfs, to prevent seeing "through" walls/doors, and to support seeing "edges" without actually seeing the atom itself. Most of the rest of it is pipelining done to accommodate how icons are cut. ## Path To Merge Almost* all sprites and code is done at this point. There are some things missing both on and off the bounty list, but that will be the case forever unless we force upstream (you guys) to stop adding new shit that doesn't fit the style. I plan on accepting and integrating prs to the current working repo <https://github.com/wall-nerds/wallening> up until a merge, to make contribution simpler and allow things like bounties to close out more easily This pr is quite bulky, even stripping away map changes it's maybe 7000 LOC (We have a few maps that were modified with UpdatePaths, I am also tentatively pring our test map, for future use.) This may inhibit proper review, although that is part of why I am willing to make it despite my perfectionism. Apologies in advance. Due to the perspective shift, a lot of mapping work is going to need to be done at some point. This comes in varying levels of priority. Many wallmounts are offset by hand, some are stuck in the wall/basically cannot be placed on the east/west/north edges of walls (posters), some just don't look great good in their current position. Tests are currently a minor bit yorked, I thought it was more important to get this up then to clean them fully. ## What does it look like?       ## Credits <details> <summary>Historical Mumbojumbo</summary> I am gonna do my best to document how this project came to be. I am operating off third party info and half remembered details, so if I'm wrong please yell at me. This project started sometime in late 2020, as a product of Rohesie trying to integrate and make easier work from Mojave Sun (A recently defunct fallout server) with /tg/. Mojave Sun (Apparently this was LITERALLY JUST infrared baron, that man is insane) was working with tall walls, IE walls that are 48px tall instead of the normal 32. This was I THINK done based off a technical prototype from aao7 proving A it was possible and B it didn't look like dogwater. This alongside oranges begging the art team for 3/4th walls (he meant TGMC style) lead to Rohesie bringing on contributors from general /tg/, including actionninja who would eventually take over as technical lead and Kryson, who would define /tg/'s version of the artstyle. Much of the formative aspects of this project are their work. The project was coming along pretty well for a few months, but ran into serious technical issues with `SIDE_MAP`, a byond map_format that allows for simpler 3/4th rendering. Due to BULLSHIT I will not detail here, the map format caused issues both at random with flickering and heavily with multiz. Concurrent with this, action stepped down after hacking out the rendering tech and starting work on an icon cutter that would allow for simpler icon generation, leaving ninjanomnom to manage the project. Some time passed, and the project stalled out due to the technical issues. Eventually I built a test case for the issues we had with `SIDE_MAP` and convinced lummox jr (byond's developer) to explain how the fuckin thing actually worked. This understanding made the project theoretically possible, but did not resolve the problems with multi-z. Resolving those required a full rework of how rendering like, worked. I (alongside tattle) took over project development from ninjanomnom at this time, and started work on Plane Cube (#69115), which when finished would finally make the project technically feasible. The time between then and now has been slow, progressive work. Many many artists and technical folks have dumped their time into this (as you can see from the credits). I will get into this more below but I would like to explicitly thank (in no particular order) tattle, draco, arcanemusic, actionninja, imaginos, viro and kylerace for keeping the project alive in this time period. I would have curled up into a ball and died if I had to do this all myself, your help has been indispensable. </details> <details> <summary>Detailed Credits</summary> Deep apologies if I have forgotten someone (I am sure I have, if someone is you please contact me). I've done my best to collate from the git log/my memory. Thanks to (In no particular order): Raccoff: Being funny to bully, creating threshold decals for airlocks aa07: (I think) inspiring the project ActionNinja: Laying the technical rock we build off, supporting me despite byond trying to kill him, building the icon cutter that makes this possible ArcaneMusic: Artistic and technical work spanning from the project's start to literally today, being a constant of motivation and positivity. I can't list all the stuff he's done Armhulen: Key rendering work (he's the reason thindows render right), an upbeat personality and a kick in the ass. Love you arm Azlan: Damn cool sprites, consistently Ben10Omintrix: You know ben showed up just to make basic mobs work, he's just fuckin like that man BigBimmer: A large amount of bounty work, alongside just like, throwing shit around. An absolute joy to work with Capsandi: Plaques, blastdoors, artistic work early on CapybaraExtravagante: Rendering work on wall frames Draco: SO MUCH STUFF. Much of the spritework done over the past two years is his, constantly engaged and will take on anything. I would have given up if not for you Floyd: Early rendering work, so early I don't even know the details. Enjoy freedom brother Imaginos16: A guiding hand through the middle years, handled much of the sprite review and contribution for a good bit there Iamgoofball: A dedication to detail and aesthetic goals, spends a lot of effort dissecting feedback with a focus on making things as good as they can be at the jump Infrared: Part of the impetus for the project, made all the xenomorph stuff in the MS style Jacquerel: A bunch of little upkeep/technical things, has done so much sprite gruntwork (WHY ARE THERE SO MANY PAINTING TYPES) Justice12354: Solved a bunch of error sprites (and worked out how to actually make prs to the project) Thanks bro! Kryson: Built the artstyle of the project, carrying on for years even when it was technically dying, only stopping to casually beat cancer. So much of our style and art is Kryson KylerAce: Handled annoying technical stuff for me, built window frame logic and fully got rid of grilles. LemonInTheDark: Rendering dirtywork, project management and just so much fucking time in dreammaker editing sprites Meyhazah: Table buttons, brass windows and alll the old style doors Mothblocks: Has provided constant support, gave me a deadline and motivation, erased worries about "it not being done", gave just SO much money to fill in the critical holes in sprites. Thanks moth MTandi: Contributed art despite his own blackjack and hookers club opening right down the road, I'm sorry I rolled over some of your sprites man I wish we had finished earlier Ninjanomnomnom: Consulted on gags issues, kept things alive through some truly shit times oranges: This is his fault Rohesie: Organized the effort, did much of the initial like, proof of concept stuff. I hope you're doin well whatever you're up to. san7890: Consulting on mapper UX/design problems, being my pet mapper Senefi: Offsetting items with a focus on detail/the more unused canidates SimplyLogan: Detailed map work and mapper feedback, personally very kind even if we end up talking past each other sometimes. Thank you! SpaceSmithers: Just like, random mapping support out of nowhere, and bein a straight up cool dude Tattle: A bunch of misc project management stuff, organizing the discord, managing the test server, dealing with all the mapping bullshit for me, being my backup in case of bus. I know you think you didn't do much but your presence and work have been a great help Thunder12345: Came out of nowhere and just so much of the random bounties, I'm kind of upset about how much we paid him Time-Green: I hooked him in by fucking with stuff he made and now he's just doin shit, thanks for helping out man! Twaticus: Provided artistic feedback and authority for my poor feeble coder brain, believed in the project for YEARS, was a constant source of ❤️ and affirmation unit0016: I have no god damn idea who she is, popped out of nowhere on the github one day and dealt with a bunch of annoying rendering/refactoring. Godspeed random furry thank you for all your effort and issue reports Viro: A bunch of detailed spriting moving towards 3/4ths, both on and off the wallening fork. If anyone believed this project would be done, it was viro Wallem: Artistic review and consultation, was my go-to guy for a long time when the other two spritetainers were inactive Waltermeldon: Cracked out a bunch of rendering work, he's the reason windows look like not dogwater. Alongside floyd and action spent a TON of time speaking to lummox/unearthing how byond rendering worked trying to make this thing happen ZephyrTFA: Added directional airlock helpers, dealt with a big fuckin bugaboo that was living in my brain like it was nothing. Love you brother And finally: The Mojave Sun development team. They provided a testbed for the idea, committed hundreds and hundreds of hours to the artstyle, and were a large reason we caught issues early enough to meaningfully deal with them. Your work is a testament to what longterm effort and deep detailed care produce. I hope you're doing well whatever you're up to. Go out with a bang! </details> ## Changelog 🆑 Raccoff, aa07, ActionNinja, ArcaneMusic, Armhulen, Azlan, Ben10Omintrix, BigBimmer, Capsandi, CapybaraExtravagante, Draco, Floyd, Iamgoofball, Imaginos16, Infrared, Jacquerel, Justice12354, Kryson, KylerAce, LemonInTheDark, Meyhazah, Mothblocks, MTandi, Ninjanomnom, oranges, Rohesie, Runi-c, san7890, Senefi, SimplyLogan, SomeAngryMiner, SpaceSmithers, Tattle, Thunder12345, Time-Green, Twaticus, unit0016, Viro, Waltermeldon, ZephyrTFA with thanks to the Mojave Sun team! add: Resprites or offsets almost all "tall" objects in the game to match a 3/4ths perspective add: Bunch of rendering mumbo jumbo to make said 3/4ths perspective work /🆑 --------- Co-authored-by: Jacquerel <hnevard@gmail.com> Co-authored-by: san7890 <the@san7890.com> Co-authored-by: = <stewartareid@outlook.com> Co-authored-by: Capsandi <dansullycc@gmail.com> Co-authored-by: ArcaneMusic <hero12290@aol.com> Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com> Co-authored-by: SomeAngryMiner <53237389+SomeAngryMiner@users.noreply.github.com> Co-authored-by: KylerAce <kylerlumpkin1@gmail.com> Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com> Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com> Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com> Co-authored-by: Runi-c <5150427+Runi-c@users.noreply.github.com> Co-authored-by: Roryl-c <5150427+Roryl-c@users.noreply.github.com> Co-authored-by: tattle <article.disaster@gmail.com> Co-authored-by: Senefi <20830349+Peliex@users.noreply.github.com> Co-authored-by: Justice <42555530+Justice12354@users.noreply.github.com> Co-authored-by: BluBerry016 <50649185+unit0016@users.noreply.github.com> Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: SimplyLogan <47579821+loganuk@users.noreply.github.com> Co-authored-by: Emmett Gaines <ninjanomnom@gmail.com> Co-authored-by: Rob Bailey <github@criticalaction.net> Co-authored-by: MMMiracles <lolaccount1@hotmail.com> |
||
|
SyncIt21
|
b949b7c7fb |
Simple mouse drop improvements (#84406)
## About The Pull Request 1. Mouse drop now uses `CanReach()` which is more versatile instead of `Adjacent()` for adjacency checks 2. `CanReach()` & `DirectAccess()` are now part of `atom`. It's been moved up from `atom/movable` 3. It won't again check for adjacency inside `can_perform_action()` saving some overhead 4. Removing the nested `if` conditions from code is always a plus ## Changelog 🆑 code: improved mouse drag & drop code /🆑 |
||
|
carlarctg
|
ff836e10be |
First Genetics Content in 5 Years (Adds new positive mutations!) (#83652)
## About The Pull Request Sister PR to #83439, that needs to be merged before this. Adds a plethora of new positive mutations to the game! Mutations now have a variable that directly adds and removes traits instead of manually doing so for idk Tripled cryobeam range. Made the mushroom hallucinogen's code more readable. - Adrenaline Rush Trigger your body's adrenaline response, granting you 10 * P units of pump-up, synaptizine, and determination. After 25 seconds, you crash, recieving 7 * S units of tiring and dizzying solution. Can be Energized, Powered, and Synchronized. - Mending Touch Transfer injuries from the target to yourself! Heal 35 * P damage, recieving up to 35 * S damage in turn. Transfers moderate wounds, fire stacks, and attempts to parallel limb-to-limb damage. Has bonuses for pacifist players. Can be Energized, Powered, and Synchronized. - Elastic Arms Your arms become floppy and you can interact with things as if you were adjacent to them from one tile further! Does not work through walls or dense objects, and you become unable to lift huge items, pull large corpses, and you get chunky fingers. Split temperature adaptation into three: - Cold Adaptation Gain cold immunity, gain ice slip immunity! - Heat Adaptation Gain heat and ash storm immunity - Thermal Adaptation Resist both cold and heat, but no extra fancies. The sprite is green now! Pressure Adapt has a purple sprite. You can mix the cold mutations with Fiery Sweat to make these new ones: - Cindikinesis Instead of summoning snow, you can now summon... ash. Wow. Very cool. - Pyrokinesis You can fire fire now! Fires beams of heat that, unlike the temperature gun, actually ignite on hit. Higher instability cost than its sister mutation. The changes have been themed primarily around classic superhero gimmicks. Genetics feels like a natural spawning point for superheroes, and its mutations show this via the good ol' 'radiation made me fire eye lasers' hero backstory. Adding more ways to be a superhero is fun. Also, added two new speech mutations: - Trichromatic Larynx Every word you say is now either red, green, or blue! - Heckacious Larynx (Trichromatic Larynx x Wacky) You sound, well. Absolutely ridiculous. Spectacularly silly. Profoundly wacky. Don't give it to the clown. Unlocked the Elvis mutation as well. ## Why It's Good For The Game > Adds a plethora of new positive mutations to the game! Genetics is in desperate need of new content, all it's had for years is a slow gutting and removal of the few things it does have. Hulk is, being real, stupid, dumb, stagnated, and overpowered, but it's been begrudgingly accepted because genetics is quite literally just, nothing without it. I'm here to add the somethings to genetics and add some more variety (and no i'm not touching hulk) > Mutations now have a variable that directly adds and removes traits instead of manually doing so for every mutation. Less stupid > Tripled cryobeam range. Shit joke mutation is now long-range shit joke mutation! > Made the mushroom hallucinogen's code more readable. Slightly OOS because I was going to add color blind mutations but decided not to creep. This piece o shit code has been hurting my head for years and now that I've finally understood it I want to make sure others don't go through that pani. > - Adrenaline Rush A quick burst of some mild chemicals at the cost of eventual nausea, sounds like a fair trade to me! If you're already on the ground, this isn't going to do anything. > - Mending Touch Healing is something that's lacking from the mutations, and this puts a fun spin on it, making the caster a damage pincushion as they heal and absorb damage. > - Elastic Arms Classic superhero power, very funny, lots of silly and sandbox potential. Has innate drawbacks because 1. thematic and 2. it's pretty strong > Split temperature adaptation into three: They combine into the same thing it used to be, so don't freak out. This just adds some separation between the immune types, for things like themed superheroes. > - Cold Adaptation Perhaps mildly concerning, but I think this might be a fun spin on it? TODO: make hiking boots effect? > - Heat Adaptation Nothing to say. It's cool. > - Thermal Adaptation Nothing wrong with this mutation so it stays in > You can mix the cold mutations with Fiery Sweat to make these new ones: How can we have frozone and not, uh human torch or something. why are there no heavy hitter fire superheroes in marvel or dc??? > - Cindikinesis Can't really summon an equivalent to snow that's actually useful, so here's this instead. Clown might like it, or maybe the chemist. > - Pyrokinesis The ignition effect is fairly weak and mostly a deterrent. I think this is the most dangerous ranged mutation in the game, which is kinda sad. > - Trichromatic Larynx Colors are fun! We have speech mutations that change words but none that change their color. Though, to be fair, this was mostly added for the mutation below's combination. > - Heckacious Larynx (Trichromatic Larynx x Wacky) I felt that Wacky wasn't nearly wacky enough. It just made your speech comic sans. That's great and all, but. It's not much? This will be a truly clownly mutation, the Genetics equivalent of a HONK mech. I made it a combination mutation specifically to restrain its power level. > Unlocked the Elvis mutation as well. Was there a reason to lock this? ## Changelog 🆑 add: Added tons of new mutations to Genetics, alongside some recipes! add: Thermal Adaptation has been made a combination mutation from the stronger but narrower Cold and Heat adaptations. balance: Cryobeams have 9 tile range, and fiery sweat doesn't cause spread on contact. image: Added some neat new sprites for the new mutations, and added a greyscale version of the magic hand sprites. code: Infinitesmally improved mutation code. /🆑 |
||
|
SyncIt21
|
9c9a5d28ff |
Some alt & ctrl click improvements (#84203)
## About The Pull Request Improved code quality of both so they resemble each other. Some of the new specs are as follows 1. Moved` COMSIG_CLICK_ALT` & `COMSIG_CLICK_ALT_SECONDARY` up i.e. before `can_perform_action()` making them pure hooks not bound by any action checks giving components full control over them 2. Removed range check(`CAN_I_SEE`) & view check(`is_blind()`) out of the base alt click proc. They now only apply to living mobs and don't apply to ghosts(ghosts don't get blind & see everything) & revenants (the range check still applies for revenants though). This was actually a bug because these 2 checks were only meant to see if the loot panel could be opened (as stated in https://github.com/tgstation/tgstation/pull/83736#discussion_r1628097941) but because they are at the top of the proc they also apply to all alt click actions which is not intended. Also, by moving these checks down to mob subtype levels some of the snowflake checks like this https://github.com/tgstation/tgstation/blob/7579e0e1734ee40b33ce1fd3fc5c2dd08fe30404/code/_onclick/click_alt.dm#L23 can be removed. We should not check for subtypes within the parent type proc but instead have subtypes override their parent procs to implement custom behaviour 3. Removed redundant signals like` COMSIG_XENO_SLIME_CLICK_ALT` in favour of just `COMSIG_MOB_ALTCLICKON` 4. While looking for alt click signal overrides I found alt click for style meter was run timing, that's fixed now ## Changelog 🆑 fix: alt click runtime no more when using style meter code: improved alt & ctrl click code /🆑 |
||
|
SyncIt21
|
47be0bffc2 |
Ctrl click refactor (#83784)
## About The Pull Request Same idea as #82656 but for ctrl click & ctrl shift click cause why not - Does your signal & `can_perform_action()` checks using `interaction_flags_click` flags before delegating the event down to `ctrl_click()` proc. - The one new change now is that `ctrl_click()` proc is now blocking, meaning returning `CLICK_ACTION_SUCCESS` or `CLICK_ACTION_BLOCKING` will stop the object from getting grabbed/pulled. So remember to return these values if you want to stop the grab action or return `NONE` if you want to process the click but still want the object to get grabbed as well ## Changelog 🆑 refactor: Ctrl click & Ctrl shift click has been refactored. Please report bugs on GitHub /🆑 |
||
|
MrMelbert
|
ff6b41aa07 |
Afterattack is dead, long live Afterattack (#83818)
## About The Pull Request - Afterattack is a very simple proc now: All it does is this, and all it's used for is for having a convenient place to put effects an item does after a successful attack (IE, the attack was not blocked)  - An overwhelming majority of afterattack implementations have been moved to `interact_with_atom` or the new `ranged_interact_with_atom` I have manually tested many of the refactored procs but there was 200+ so it's kinda hard ## Why It's Good For The Game Afterattack is one of the worst parts of the attack chain, as it simultaneously serves as a way of doing random interactions NOT AT ALL related to attacks (despite the name) while ALSO serving as the defacto way to do a ranged interaction with an item This means careless coders (most of them) may throw stuff in afterattack without realizing how wide reaching it is, which causes bugs. By making two well defined, separate procs for handing adjacent vs ranged interactions, it becomes WAY WAY WAY more easy to develop for. If you want to do something when you click on something else and you're adjacent, use `interact_with_atom` If you want to do something when you click on something else and you're not adjacent, use 'ranged_interact_with_atom` This does result in some instances of boilerplate as shown here:  But I think it's acceptable, feel free to oppose if you don't I'm sure we can think of another solution ~~Additionally it makes it easier to implement swing combat. That's a bonus I guess~~ ## Changelog 🆑 Melbert refactor: Over 200 item interactions have been refactored to use a newer, easier-to-use system. Report any oddities with using items on other objects you may see (such as surgery, reagent containers like cups and spray bottles, or construction devices), especially using something at range (such as guns or chisels) refactor: Item-On-Modsuit interactions have changed slightly. While on combat mode, you will attempt to "use" the item on the suit instead of inserting it into the suit's storage. This means being on combat mode while the suit's panel is open will block you from inserting items entirely via click (but other methods such as hotkey, clicking on the storage boxes, and mousedrop will still work). refactor: The detective's scanner will now be inserted into storage items if clicked normally, and will scan the storage item if on combat mode /🆑 |
||
|
SyncIt21
|
d91650ea39 | Alt right click refactor (#83736) | ||
|
Ben10Omintrix
|
761b14ef7c |
lavaland raptors (#82537)
## About The Pull Request adds raptors to lavaland. these are creatures that have been created through countless xenobiological experiments by nanotrasen to breed an animal that can withstand the harsh conditions of lavaland and aid miners. theres now a new ranch miners can access bottom right to the mining base  this ranch starts somewhat empty as most raptors have escaped containment and are now scattered all across lavaland, u can find them and return them to ur ranch. in order to tame a raptor, u first need to prove to it that ur a capable master. when u try to ride it, a little minigame prompt will pop up  in this game, the bird's icon rapidly changes direction and u have to quickly click the arrow thats OPPOSITE to the direction its facing several times before the direction changes. if you fail 3 times itll knock you off and run away, however if u win it will deem u a suitable master and listen to your orders. There's many different breeds of raptors you can find across lavaland, all with different capabilities: red raptors: these excel at combat and can be very useful for dealing with lavaland mobs or defending the node drone yellow raptors: are very speedy mounts, theyll get u from point A to point B in record time green raptors: they are the tankiest type of raptor and are very good miners. while mounted, they will clear any rock walls in their path purple raptors: can store items in them. they have a decent storage size allowing players to carry more items across trips white raptors: are able to heal other injured raptors. having one in ur party would be very useful as they can nurse the combat raptors back to full health when they need it blue raptors: produce very nutritious milk with healing capabilities. having 1 or 2 of these back at ur ranch would be very useful black raptors: by far the rarest breed, its very unlikely that ull be able to get one of these, but in the case u do, they have the combat capabilities of the red raptor, speed of the yellow raptor, and tankiness of the green raptor. Breeding different colored raptors together can net u an entirely new colored raptor. each breed has atleast 1 guaranteed combination of parents that it will result out of. you will also need to maintain a good friendship bond with ur raptors, this is done by feeding them, grooming them, and petting them. u can see the strength of ur bond by SHIFT clicking them. more hearts indicate a stronger bond  having higher friendship bonds means ur raptors will perform better in combat, and in the case of blue raptors, they will produce more milk. Maintaining friendship bonds with baby raptors and keeping them happy will also encourage them to grow faster U can also analyze raptors using the new raptor-dex device available at ur ranch  the inherit modifiers indicate how strong this raptor's offspring will be. raptors inherit attack and health stats from both their parents, breeding raptors with higher inherit modifiers means the offspring will be stronger. raptors will also inherit some traits from their parents that will change how they will act around u and around other raptors, some of them being: Playful: raptors will play with their masters and tease them motherly: raptors will care for baby raptors, this will encourage baby raptors to grow quicker depressed: means its hard to keep this raptor happy and friendship bonds will deteriorate faster if not given enough care. coward: makes them flee combat if severly injured, ditching u to the wolves trouble maker: makes them attack other raptors at the ranch. however, trouble maker raptors will not attack other trouble maker raptors, instead they will form posses and bully raptors together. it might be a good idea to isolate them from the other raptors raptors primarily consume ores. to feed raptors, you need to place ore into the food troughs at the ranch. they are too civilized to eat ores off the ground or directly from ur hand, they will only eat it if its in their trough  beautiful raptor sprites by spessmenart! (rest are codersprites) ## Why It's Good For The Game adds a new layer to lavaland mobs, and gives miners new interesting tools and ways to tackle the challenges of lavaland. ## Changelog 🆑 sheets, spacemenart, ben10omintrix, goofball, infrared baron, aofie add: adds lavaland raptors and the raptor ranch /🆑 --------- Co-authored-by: Iamgoofball <iamgoofball@gmail.com> |
||
|
Jeremiah
|
8e3f635b98 |
Alt click refactor (#82656)
## About The Pull Request Rewrites how alt click works. Based heavily on #82625. What a cool concept, it flows nicely with #82533. Fixes #81242 (tm bugs fixed) Fixes #82668 <details><summary>More info for devs</summary> Handy regex used for alt click s&r: `AltClick\((.*).*\)(\n\t.*\.\.\(\))?` `click_alt($1)` (yes I am aware this only copies the first arg. there are no other args!) ### Obj reskins No reason for obj reskin to check on every single alt click for every object. It applies to only a few items. - Moved to obj/item - Made into signal - Added screentips ### Ventcrawling Every single atmospherics machine checked for ventcrawling capability on alt click despite only 3 objects needing that functionality. This has been moved down to those individual items. </details> ## Why It's Good For The Game For players: - Alt clicking should work more logically, not causing double actions like eject disk and open item window - Added context menus for reskinnable items - Removed adjacency restriction on loot panel For devs: - Makes alt click interactions easier to work with, no more click chain nonsense and redundant guard clauses. - OOP hell reduced - Pascal Case reduced - Glorious snake case ## Changelog 🆑 add: The lootpanel now works at range. add: Screentips for reskinnable items. fix: Alt click interactions have been refactored, which may lead to unintentional changes to gameplay. Report any issues, please. /🆑 |
||
|
Jeremiah
|
d554ab7766 |
RPG Loot: Revisited & READY (#82533)
## About The Pull Request Revival of #72881 A new alt click window with a tarkov-y loading spinner. Replaces the object item window in stat panel. ## Videos <details> <summary>vids</summary> toggleable grouping:  now lists the floor as first obj:  in action:  </details> ## features: - search by name - 515 image generator is much faster than alt click menu - opening a gargantuan amount of items shouldnt freeze your screen - groups similar items together in stacks by default, toggleable - shows tile as first item - <kbd>Shift</kbd> and <kbd>Ctrl</kbd> compatible with LMB 🖱️ - RMB points points at items (sry i could not get MMB working) - key <kbd>Esc</kbd> to exit the window. For devs: - A new image generation tech. - An error refetch mechanic to the Image component - It does not "smart track" the items being added to the pile, just reopen or refresh. This was a design decision. ## Why It's Good For The Game Honestly I just dislike the stat panel Fixes #53824 Fixes  ## Changelog 🆑 add: Added a loot window for alt-clicking tiles. del: Removed the item browser from the stat panel. /🆑 --------- Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com> Co-authored-by: AnturK <AnturK@users.noreply.github.com> Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> |
||
|
MrMelbert
|
e21dc5fec7 |
Kicks Martial Arts out of the attack chain (yippee), makes it use signals, plus a large clean up of existing martial arts (#81097)
## About The Pull Request - Kicks Martial Arts out of the attack chain. - All Martial Arts attacks are now handled via unarmed attack or grab signals - This means all martial arts are now technically on the living level, allowing any mob that can unarmed attack to martial arts. Sort of. YMMV. - All martial arts block checking is now handled by the arts themselves, meaning you can selectively decide for a martial arts strike to not be blocked. Maybe good for the future. - A comprehensive cleanup of all existing martial arts. Improving var names, code, adding some missing animation calls, etc. Fixes #74829 ## Why It's Good For The Game Untangles the mess that is martial arts, making it a lot easier to work with the attack chain and making it overall a ton more consistent. ## Changelog 🆑 Melbert refactor: Big martial arts refactor, they should now overall act a ton more consistent. Also technically any mob can do martial arts. Let me know if something is funky. /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
MrMelbert
|
d5c547e459 |
Fixes COMSIG_LIVING_EARLY_UNARMED_ATTACK arguments (#80783)
## About The Pull Request Fixes #80566 Fixes the wrong arguments being passed to `COMSIG_LIVING_EARLY_UNARMED_ATTACK`. It now properly receives the proximity flag. Changes clicking with handcuffs to no longer always assume no proximity. Replaces some checks for hands blocked to some checks for `can_unarmed_attack` (which, currently, JUST checks for hands blocked, but this is good for future reasons, just in case) ## Changelog 🆑 Melbert fix: Strong arm implant users can shove more correctly. /🆑 |
||
|
Emmett Gaines
|
96d7e9c690 |
Invisibility refactor (#78908)
This adds a tracker for sources of invisibility and a priority system. I needed this for another thing so I'm doing this first since it touches a lot of code. As for the bugs fixed in the changelog, it's only what I noticed while going through everything and there's likely a few more things fixed with this. This should be testmerged for a while, I'll bring this out of draft when it feels safe. 🆑 admin: Invisimin can now be used on mobs that are already invisible, whether through temporary or permanent effects. fix: Monkeyize/Humanize mob transformations no longer permanently reveal invisible mobs if they had effects making them invisible otherwise. fix: Objects with the undertile element that have been made invisible through other means are no longer revealed by being uncovered. /🆑 |
||
|
MrMelbert
|
9664d24c13 |
Refactors UnarmedAttack so we don't have like 4 Unarmed Attack signals, kills two more snowflake species procs (#78991)
## About The Pull Request - Deletes `spec_unarmedattack` - Deletes `spec_unarmedattacked` - Replaces `COMSIG_HUMAN_EARLY_UNARMED_ATTACK` with `COMSIG_LIVING_EARLY_UNARMED_ATTACK` - Replaces uses of `COMSIG_HUMAN_MELEE_UNARMED_ATTACK` with `COMSIG_LIVING_EARLY_UNARMED_ATTACK` - Fixes(?)(I've never seen this work) / Elementizes Monkey ability to bite while handcuffed - Monkey clever `attack paw` / `attack hand` thing is now handled the same on the human level (via `resolve_unarmed_attack`) ## Why It's Good For The Game Atomized from swing branch. I was really annoyed with these two signals, this kinda unifies the behavior between living and human mobs (they were already quite similar). One thing of note is that this will make dis-coordinated humans use `attack_paw` rather than `attack_hand`, so they'll bite people instead of punching them. I'm not sure if this is what we want, if we wanna tweak that before then I can by all means. ## Changelog 🆑 Melbert refactor: Refactored unarmed attacking mechanisms, this means dis-coordinated humans will now bite people like monkeys (like how coordinated monkeys punch people like humans?) refactor: Dis-coordinated humans smashing up machines now use their hands, rather than their paws /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
san7890
|
4b8de7b79f |
Refactors the notransform variable into a trait. (#78146)
## About The Pull Request Hey there, There were more than a few times (like in cinematic code) where we might need to accurately know the source of what's adding this trait (or have multiple sources for the whole 'we don't want this mob to do shit while we transform this mob'), so in order to rectify this potential issue, let's refactor it into a trait. ## Why It's Good For The Game Some code already declared that there might be issues with this being a boolean var (with no way of knowing _why_ we don't want this mob to not transform (or not do anything idk). Let's remove those comments and any future doubt in those instances with the trait macros. Also, stuff like `TRAIT_IMMOBILIZED` which does a similar thing in many contexts was already a trait that was regularly added in conjunction with flipping the variable, so we're able to flatten all that stuff into `add_traits()` and `remove_traits()` now. nice I also cleaned up quite a bit of code as I saw it, let me know if it should be split out but I guarantee that if I didn't do it- no one will for the next two years. ## Changelog 🆑 refactor: If you transform into another mob and notice bugs with interacting with the game world, please create a bug report as this framework was recently refactored. /🆑 Probably fucked up somewhere, lmk --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
|
san7890
|
31f1924324 |
Refactors Morphs into Basic Mobs (there is now a swag action for morphification) (#77503)
## About The Pull Request I was bored, so did this. Probably one of the neatest refactors I've done, sorry if there's some oddities because I was experimenting with some other stuff in this so just tell me to clean them up whenever I can. Anyways, morphs are basic mobs now. We are able to easily refactor the whole "eat items and corpses" stuff in the basic mob framework, but the whole "morph into objects and people" turned out to be a bit trickier. That was easily rectified with a datum mob cooldown action and copy-pasting the old code into that code, as well as doing some nice stuff with traits and signals to ensure the one-way communication from the action to the mob. Old Morph AI didn't seem to be existant whatsoever, they inappropriately leveraged some old procs and I have no idea how to make it work with new AI. They DEFINITELY don't spawn outside of admin interference/ the event anymore, and will always be controlled by a player, so this shouldn't be too bad of an issue. I gave them something to seem alive just in case though, but I think adding legitimate prop-hunt AI would be such a laborious task that I am unwilling to do it in this PR. ## Why It's Good For The Game If admins want to add the ability for Ian to assume the form of the HoP, they can do that now! The datum action cooldown is quite nice for simple and basic mobs... but it is currently not compatible with carbons. That is not within scope for this PR, but I am dwelling on ways to extend it to carbon but they all sound really awfully bad. Also morphs are smarter, and we tick another simple animal in need of refactoring off the list. ## Changelog 🆑 refactor: Morphs are now basic mobs with a nice new ability to help you change forms rather than the old shift-click method, much more intuitive. admin: With the morph rework comes a new ability you can add to mobs, "Assume Form". Feel free to add that to any simple or basic mob for le funnies as Runtime turns into a pen or something. /🆑 ~~Does anyone know if there's a (sane) way to alias a cooldown action as a keypress? I can't think of a good way to retain the old shift-click functionality, because that does feel _kinda_ nice, but I think it can be lived without.~~ I added it. Kinda fugly but whatever. |
||
|
John Willard
|
06ca7a4481 |
Hud screens now set hud owner in Initialize. (#76772)
## About The Pull Request Adds an arg in huds' screens to add the hud owner in the Initialize, instead of manually setting it every time we need to. This is already done in ``New()`` for lobby screens, which I left intact as lobby screens are used for new players, and are given out before atoms are Initialized. Everything else, however, uses Initialize, so it does not mess with any other args in their own Initializes (like the Escape menu). This also allows us to set the screens' HUDs as a private var, to ensure this won't be messed with in the future. Lastly I replaced instances of ``client`` with ``cannon_client`` to be consistent with a lot of other parts of hud code. ## Why It's Good For The Game Huds are easy to break when they do not have a hud owner, and for something as important as that I believe it should be something you opt-out of when you don't want it, rather than something you opt-into by manually setting hud owner every time. This cuts down on a lot of copy paste in hud code for humans, aliens, etc. ## Changelog 🆑 refactor: Huds now have their hud owner set in Initialize /🆑 |
||
|
san7890
|
ccef887efe |
Lints Against Unmanaged Local Defines (#74333)
# MAINTAINER - USE THE BUTTON THAT SAYS "MERGE MASTER" THEN SET THE PR TO AUTO-MERGE! IT'S MUCH EASIER FOR ME TO FIX THINGS BEFORE THEY SKEW RATHER THAN AFTER THE FACT. ## About The Pull Request Hey there, This took a while to do, but here's the gist: Python file now regexes every file in `/code` except for those that have some valid reason to be tacking on more global defines. Some of those reasons are simply just that I don't have the time right now (doing what you see in this PR took a few hours) to refactor and parse what should belong and what should be thrown out. For the time being though, this PR will at least _halt_ people making the mistake of not `#undef`ing any files they `#define` "locally", or within the scope of a file. Most people forget to do this and this leads to a lot of mess later on due to how many variables can be unmanaged on the global level. I've made this mistake, you've made this mistake, it's a common thing. Let's automatically check for it so it can be fixed no-stress. Scenarios this PR corrects: * Forgetting to undef a define but undeffing others. * Not undeffing any defines in your file. * Earmarking a define as a "file local" define, but not defining it. * Having a define be a "file local" define, but having it be used elsewhere. * Having a "local" define not even be in the file that it only shows up in. * Having a completely unused define* (* I kept some of these because they seemed important... Others were junked.) ## Why It's Good For The Game If you wanna use it across multiple files, no reason to not make it a global define (maybe there's a few reasons but let's assume that this is the 95% case). Let me know if you don't like how I re-arranged some of the defines and how you'd rather see it be implemented, and I'd be happy to do that. This was mostly just "eh does it need it or not" sorta stuff. I used a pretty cool way to detect if we should use the standardized GitHub "error" output, you can see the results of that here https://github.com/san7890/bruhstation/actions/runs/4549766579/jobs/8022186846#step:7:792 ## Changelog Nothing that really concerns players. (I fixed up all this stuff using vscode, no regexes beyond what you see in the python script. sorry downstreams) |
||
|
Jacquerel
|
705f7a419c |
Refactor Statue & Creature unobserved behaviour (#73630)
## About The Pull Request While I was touching the Creature file for another PR (#73629) I noticed that an identical proc was implemented here and on Statue. I moved it into a component and managed to hook it into signals which have return flags. This required a bit of a refactor of their abilities too, but that was for the best because one of them had a reimplementation of Jaunt which could have just been a subtype of Jaunt, and none of their abilities had icons. I also made `spell` send `COMSIG_MOB_ABILITY_STARTED` in `PreActivate` because it completely overrides the parent and doesn't do that as a result. ## Why It's Good For The Game I'll be honest this is mostly because I was looking at the code and didn't like it, I don't think there were any bugs related to this but it does reduce chat spam a little bit? It should make this behaviour more maintainable and useful in the future, as we're not copying and pasting multiple procs between different files (for both this behaviour and jaunting). ## Changelog 🆑 refactor: The actions of Statues and Creatures which can't be used while seen now share logic, and will not spam chat with feedback. /🆑 |
||
|
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>
|
||
|
Tim
|
6d12dc69ef |
Refactor /mob/living/carbon/alien/humanoid to be /mob/living/carbon/alien/adult (#70481)
|
||
|
LemonInTheDark
|
23bfdec8f4 |
Multiz Rework: Human Suffering Edition (Contains PLANE CUBE) (#69115)
About The Pull Request I've reworked multiz. This was done because our current implementation of multiz flattens planes down into just the openspace plane. This breaks any effects we attach to plane masters (including lighting), but it also totally kills the SIDE_MAP map format, which we NEED for wallening (A major 3/4ths resprite of all wall and wall adjacent things, making them more then one tile high. Without sidemap we would be unable to display things both in from of and behind objects on map. Stupid.) This required MASSIVE changes. Both to all uses of the plane var for reasons I'll discuss later, and to a ton of different systems that interact with rendering. I'll do my best to keep this compact, but there's only so much I can do. Sorry brother. Core idea OK: first thing. vis_contents as it works now squishes the planes of everything inside it down into the plane of the vis_loc. This is bad. But how to do better? It's trivially easy to make copies of our existing plane masters but offset, and relay them to the bottom of the plane above. Not a problem. The issue is how to get the actual atoms on the map to "land" on them properly. We could use FLOAT_PLANE to offset planes based off how they're being seen, in theory this would allow us to create lens for how objects are viewed. But that's not a stable thing to do, because properly "landing" a plane on a desired plane master would require taking into account every bit of how it's being seen, would inherently break this effect. Ok so we need to manually edit planes based off "z layer" (IE: what layer of a z stack are you on). That's the key conceit of this pr. Implementing the plane cube, and ensuring planes are always offset properly. Everything else is just gravy. About the Plane Cube Each plane master (except ones that opt out) is copied down by some constant value equal to the max absolute change between the first and the last plane. We do this based off the max z stack size detected by SSmapping. This is also where updates come from, and where all our updating logic will live. As mentioned, plane masters can choose to opt out of being mirrored down. In this case, anything that interacts with them assuming that they'll be offset will instead just get back the valid plane value. This works for render targets too, since I had to work them into the system as well. Plane masters can also be temporarily hidden from the client's screen. This is done as an attempt at optimization, and applies to anything used in niche cases, or planes only used if there's a z layer below you. About Plane Master Groups BYOND supports having different "maps" on screen at once (IE: groups of items/turfs/etc) Plane masters cannot cover 2 maps at once, since their location is determined by their screen_loc. So we need to maintain a mirror of each plane for every map we have open. This was quite messy, so I've refactored it (and maps too) to be a bit more modular. Rather then storing a list of plane masters, we store a list of plane master group datums. Each datum is in charge of the plane masters for its particular map, both creating them, and managing them. Like I mentioned, I also refactored map views. Adding a new mapview is now as simple as newing a /atom/movable/screen/map_view, calling generate_view with the appropriate map id, setting things you want to display in its vis_contents, and then calling display_to on it, passing in the mob to show ourselves to. Much better then the hardcoded pattern we used to use. So much duplicated code man. Oh and plane master controllers, that system we have that allows for applying filters to sets of plane masters? I've made it use lookups on plane master groups now, rather then hanging references to all impacted planes. This makes logic easier, and prevents the need to manage references and update the controllers. image In addition, I've added a debug ui for plane masters. It allows you to view all of your own plane masters and short descriptions of what they do, alongside tools for editing them and their relays. It ALSO supports editing someone elses plane masters, AND it supports (in a very fragile and incomplete manner) viewing literally through someone else's eyes, including their plane masters. This is very useful, because it means you can debug "hey my X is yorked" issues yourself, on live. In order to accomplish this I have needed to add setters for an ungodly amount of visual impacting vars. Sight flags, eye, see_invis, see_in_dark, etc. It also comes with an info dump about the ui, and plane masters/relays in general. Sort of on that note. I've documented everything I know that's niche/useful about our visual effects and rendering system. My hope is this will serve to bring people up to speed on what can be done more quickly, alongside making my sin here less horrible. See https://github.com/LemonInTheDark/tgstation/blob/multiz-hell/.github/guides/VISUALS.md. "Landing" planes Ok so I've explained the backend, but how do we actually land planes properly? Most of the time this is really simple. When a plane var is set, we need to provide some spokesperson for the appearance's z level. We can use this to derive their z layer, and thus what offset to use. This is just a lot of gruntwork, but it's occasionally more complex. Sometimes we need to cache a list of z layer -> effect, and then use that. Also a LOT of updating on z move. So much z move shit. Oh. and in order to make byond darkness work properly, I needed to add SEE_BLACKNESS to all sight flags. This draws darkness to plane 0, which means I'm able to relay it around and draw it on different z layers as is possible. fun darkness ripple effects incoming someday I also need to update mob overlays on move. I do this by realiizing their appearances, mutating their plane, and then readding the overlay in the correct order. The cost of this is currently 3N. I'm convinced this could be improved, but I've not got to it yet. It can also occasionally cause overlays to corrupt. This is fixed by laying a protective ward of overlays.Copy in the sand, but that spell makes the compiler confused, so I'll have to bully lummy about fixing it at some point. Behavior changes We've had to give up on the already broken gateway "see through" effect. Won't work without managing gateway plane masters or something stupid. Not worth it. So instead we display the other side as a ui element. It's worse, but not that bad. Because vis_contents no longer flattens planes (most of the time), some uses of it now have interesting behavior. The main thing that comes to mind is alert popups that display mobs. They can impact the lighting plane. I don't really care, but it should be fixable, I think, given elbow grease. Ah and I've cleaned up layers and plane defines to make them a bit easier to read/reason about, at least I think. Why It's Good For The Game <visual candy> Fixes #65800 Fixes #68461 Changelog cl refactor: Refactored... well a lot really. Map views, anything to do with planes, multiz, a shit ton of rendering stuff. Basically if you see anything off visually report it admin: VV a mob, and hit View/Edit Planes in the dropdown to steal their view, and modify it as you like. You can do the same to yourself using the Edit/Debug Planes verb /cl |
||
|
LemonInTheDark
|
3e4674ed30 |
Object Window Niceties (#69825)
* Object Window Niceties Alright. I got bored and polished up the object/alt click window. It had a few issues: First, we generated all our images in bulk, as soon as requested Second, the caching was global, despite only working on a client to client basis Third, we only generated up to 10 images. This could be fine, but the javascript code will continuiously rerender assuming unrendered images will come eventually, and they well, weren't. This caused MASSIVE clientside lag Fourth and finally, I did not like how moving away from the viewed turf lagged behind, in sync with the stat tab update. Looked bad. I've resolved all these. I solved the first three issues by reworking how obj images were generatated and managed. Rather then storing a basic cache on the subsystem, and doing all the image generation at once, we queue up image generation as we like, and generate images inside a new processing subsystem fire. This isn't the best solution, since it still eats cpu somewhat, but it's a whole lot better then the other options, outside either removing the need to getflat, or somehow predicting what items a client will want to see I've started storing three bits of info. First, a list of all the objects we currently want to display. Second, a list of atom -> image html Third, a list of atoms to imageify. This information is stored on a datum on /client, since I want this to have a lifetime linked to well, clients. I've used this datum to solve that fourth bit, using a component I made for parallax a bit back. This lets me react to our client's mob, and update the tab linked to that, rather then on a subsystem call by call basis. That's about it. Co-authored-by: san7890 <the@san7890.com> |
||
|
小月猫
|
146d0fd59d |
Fixes a couple simple issues with interactability (#69762)
first things first, back when LemonInTheDark changed the interact_range code he did a slight modification that broke the AI cards, namely, he did this (not saying its a bad change, it is actually a good change, just mentioning what change caused the issue im fixing now): now, his change does make sense, since he changed the range default to 0 instead of 1, however "null" is also used as a range, specifically for AIs, now this normally isnt an issue for the AI itself, as the AI generally gets a TRUE in its interaction checks before it gets down this deep (machines have a bypass specifically for AI), but there is one situation in which it does go this deep: AI Cards, when in an AI card the AIs interaction range is set to 0 and their interaction is disabled, thereby making it impossible for them to interact with anything, now when a player opens the card UI and enables the AIs ability to interact, this sets their range back to null, aka unlimited, the issue now however, is that since "null" is treated the same as "0", and AIs in cards dont hit the same bypasses an AI core does, Lemons change to submit a false return for 0, is also submitting false for null, meaning the AI card cannot interact with anything except the tile its on, despite having null/unlimited range.... fixed by changing the null value to infinity where it is used additionally my fix of can_interact() code apparently had the unintended side effect of not allowing rotations of machines if theres no power, i missed this entirely because thats such a specific situation, since you try rotating with APC power in most cases, it also didnt affect most machines, that said the fix was simple, just changed the proc being called to only check distance, not power. fixes #61852 and last but not least, fixes some code with the syndie bombs interactability, namely removes a redudant section, and adds a check for range, turns out there were no checks for range so you could in theory open the UI and walk away and then activate it from another location, so added a quick check to ensure you actually CAN interact with it before letting you push buttons in the UI |
||
|
Kapu1178
|
2eccf3cea0 |
Cleans up update_icons, makes the update_icon_updates_onmob element bespoke, updates CODEOWNERS (#69179)
* I just realised this is all one commit. * hail marry * fix. * FIXES IT FOR REAL * Update code/datums/elements/update_icon_updates_onmob.dm |
||
|
Mooshimi
|
d543991f51 |
ventcrawling exploit fix (#68965)
* ventcrawling * haha parenthesis moment |
||
|
Kylerace
|
77c2b7f50c |
Biddle Verbs: Queues the Most Expensive Verbs for the Next Tick if the Server Is Overloaded (#65589)
This pr goes through: /client/Click(), /client/Topic(), /mob/living/verb/resist(), /mob/verb/quick_equip(), /mob/verb/examinate(), and /mob/verb/mode() and makes them queue their functionality to a subsystem to execute in the next tick if the server is overloaded. To do this a new subsystem is made to handle most verbs called SSverb_manager, if the server is overloaded the verb queues itself in the subsystem and returns, then near the start of the next tick that verb is resumed with the provided callback. The verbs are called directly after SSinput, and the subsystem does not yield until its queue is completely finished. The exception are clicks from player input since they are extremely important for the feeling of responsiveness. I considered not queuing them but theyre too expensive not to, suffering from a death of a thousand cuts performance wise from many many things in the process adding up. Instead clicks are executed at the very start of the next tick, as the first action that SSinput completes, before player movement is processed even. A few months ago, before I died I was trying to figure out why games at midpop (40-50 people) had non zero and consistent time dilation without maptick being consistently above 28% (which is when the MC stops yielding for maptick if its overloaded). I found it out, started working on this pr, then promptly died. luckily im a bit less dead now the current MC has a problem: the cost of verbs is completely and totally invisible to it, it cannot account for them. Why is this bad? because verbs are the last thing to execute in the tick, after the MC and SendMaps have finished executing. tick diagram2 If the MC is overloaded and uses 100% of the time it allots itself this means that if SendMaps uses the amount its expected to take, verbs have at most 2% of the tick to execute in before they are overtiming and thus delaying the start of the next tick. This is bad, and im 99% sure this is the majority of our overtime. Take Click() for example. Click isnt listed as a verb but since its called as a result of client commands its executed at the end of the tick like other verbs. in this random 80 pop sybil round profile i had saved on my computer sybil 80 pop (2).txt /client/Click() has an overtime of only 1.8 seconds, which isnt that bad. however it has a self cpu of 2.5 seconds meaning 1.8/2.5 = 72% of its time is overtiming, and it also is calling 80.2 seconds worth of total cpu, which means that more than 57.7 seconds of overtime is attributed to just /client/Click() executing at the very end of a tick. the reason why this isnt obvious is just because the verbs themselves typically dont have high enough self cpu to get high enough on the rankings of overtiming procs to be noticed, all of their overtime is distributed among a ton of procs they call in the chain. Since i cant guarantee the MC resumes at the very start of the next tick due to other sleeping procs almost always resuming first: I time the duration between clicks being queued up for the next tick and when theyre actually executed. if it exceeds 20 milliseconds of added latency (less than one tenth the average human reaction time) clicks will execute immediately instead of queuing, this should make instances where a player can notice the added latency a vanishingly small minority of cases. still, this should be tm'd |
||
|
LemonInTheDark
|
22d57da140 |
Readds Alien Vore (#68312)
* Readds Alien Vore
Aliens can now eat people again. Behavior was removed by #43991 (
|
||
|
magatsuchi
|
e177956b84 | adds a null check to CanReach() (#68383) | ||
|
magatsuchi
|
7d0f393f5d |
Tsu's Brand Spanking New Storage: or, How I Learned To Pass Github Copilot As My Own Code (#67478)
Currently, storage works as a subtype of /datum/component, utilizing GetComponent() and signals to operate. While this is a pretty good idea in theory, the execution was pretty trash, and we end up with alot of GetComponent() snowflake code (something that shouldn't even need to be used frankly), and a heaping load of scattered procs that lead into one another, and procs that don't get utilized properly. Instead, this PR adds atom_storage and proc/create_storage(. . .) to every atom, allowing for the possibility of storage on quite frankly anything. Not only does this entirely remove the need for signals, but it heavily squashes down the number of needed procs in total (removing snowflake signal procs that just lead to one another), reducing overall proc overhead and improving performance. |
||
|
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 |
||
|
magatsuchi
|
bea9387458 |
refactors statpanel to use tgui API (#66971)
refactors the status panel to utilize the tgui/byond communication APIs instead of passing along href data, as well as converts the entirety of it into a datum/tgui_window Co-authored-by: Aleksej Komarov <stylemistake@gmail.com> |
||
|
MrMelbert
|
61e45109cc |
Auto-docs + code improvements + splits up status_effect.dm (#66362)
* Code improvements for status effects in general * Does this for now * Throws in a qdeleted check * A return * comment tweak * Missed some ref()s * Wrong var * Comment clarifications * Some more comment clarifications |
||
|
Tim
|
be355edab5 | Refactor incapacitated optional arguments (#63771) | ||
|
TemporalOroboros
|
6cf97ad50e |
Fixes aiming at the click catcher. (#64147)
My PR to fix pixel aiming broke aiming when you were aiming at obscured turfs. The click catcher was properly modifying the click target to be the turf under the click location, but it was passing the `ICON_X` and `ICON_Y` variables on unmodified. This means that instead of being measured from the bottom left corner of the turf you clicked on they were being measured from roughly the bottom left corner of your screen. This makes the click relevant click parsing proc also update the ICON_X and ICON_Y values of the click modifiers. |
||
|
GoldenAlpharex
|
413fd90502 |
Dullahan Partial Refactor: They Work Again Edition (#63696)
So, a few months ago I was like "hmm there's something weird going on with party pods...", which got me looking into important_recursive_hearers or something like that. I spoke about it in the coding channel and Kyler actually fixed it before I did. But I also caught a similar glitch with Dullahans, so I decided to investigate... Two months later... I present to you a partial unfuckening of the Dullahans, in that I made them fully functional once again: They only hear speech through their head (not sounds, sadly, someone else would have to tell me how to do that because I otherwise really wouldn't know how to do it in a sane way), they speak through their head, runechat-included. When you spawn a Dullahan, you're set to look through the Dullahan's eyes (so from their head), and that doesn't reset when you log off and back in, or admin-ghost and come back in your body. When you're looking through your head, your view will no longer be reset to your body upon entering a locker, which is nice to avoid not being blind while looking through your body. Dullahan heads no longer look completely lifeless and without organs. They have eyes that don't look dead and that even match the player's intended eye color. Dullahan can now properly examine things from their head, which was intended and 100% not functional. Dullahan heads now speak with the proper name of their owner, instead of having a random name attached to it at round-start. Dullahan heads are also now properly named too. Dullahans can now properly whisper, sing and do all these funny things that they were unable to do before. Dullahan whispers will now properly respect the range of the whisper. Dullahans can now succumb in hardcrit by whispering, as intended. This potentially fixes other species that worked similarly not being able to succumb, like abductors, although I didn't test if they normally could, I just know they absolutely will be able to now. When switching from Dullahans to a different species, your old head will no longer stay behind. I also added a proc for species to do some code when we get a ckey login in our mob, which could potentially be useful for other stuff in the future, but it was necessary here as the view is reliant on the client, which we want to ensure doesn't get weird view glitches like having their head's vision overlay while actually being centered on their body. I also made it so say() now takes a range argument, which is 7 by default, just so things that aren't humans can also whisper and do all those kinds of things. Going with that, there's probably a few more things that will be able to be done better thanks to this, although I haven't tested every edge case with this, but I doubt it will make much of a difference in the future. |
||
|
Ryll Ryll
|
45eb682ee6 | Adds Datum Tagging for admins (#62982) |