mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-08-26 14:39:58 +01:00
docker-container
56
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 BloopandGitHub
|
0190e64654 |
Converts simple rotation into a bespoke element (#94582)
## About The Pull Request <img width="579" height="67" alt="image" src="https://github.com/user-attachments/assets/d7a4427e-2a6e-44d3-94ba-c90a2d474984" /> Simple rotation components number in the 8-9k range per round, and each contains a needless callback datum as well. These do not need to hold any state and can be bespoke elements, and the proc to do things post_rotation can just be a normal atom proc. <details><summary>Still works as you'd expect, including items that have flag requirements like the wrench</summary>   </details> ## Why It's Good For The Game Makes a heavily used element much more lightweight, saves a few mb of memory. ## Changelog 🆑 refactor: simple rotation component has been refactored into an element Please report any bugs to github. /🆑 |
||
|
Gboster-0andGitHub
|
5fbe7ce8eb |
Makes shuttle engines no longer use weakrefs (and more minorly makes them actually give engine power) (#93116)
## About The Pull Request - Makes shuttle engines no longer use weakrefs, they now use normal references - Makes shuttle engines no longer give negative initial engine power on being unconnected ## Why It's Good For The Game > Makes shuttle engines no longer use weakrefs, they now use normal references - Weakrefs are for when we care about an object but it does not care about us, shuttles literally have a list of engines. I think they do kind of care about us and are going to hard-delete if the engines aren't deleted first. So might aswell ignore the more expensive weakrefs and use normal ones instead. > Makes shuttle engines no longer give negative initial engine power on being unconnected - So imagine this: > I wrench in the engine, cool its now connected to the shuttle > I weld the engine, fun it now provides shuttle power > I unweld the engine, damn it now does not provide shuttle power > I unwrench the engine, unsyncing it. It now provides negative power because unsyncing it made it give less power again > I cry > My shuttle now needs twice the engines it needed before Not fun, so unsyncing no longer takes away engine power. ## Changelog 🆑 fix: shuttle engines no longer provide negative power to your shuttles if you unwrench them. /🆑 |
||
|
Y0SH1M4S73RandGitHub
|
912daabe18 |
Assorted custom shuttle fixes (#93001)
## About The Pull Request This PR makes the following changes to code relevant to shuttle construction. - (Un)welding shuttle engines now only checks if the tool has 1 fuel, which is how much is already used in the process. - Constructed shuttle engines that were built from anchored machine frames start in the wrenched but unwelded state. - Fixes a runtime that occurs when expanding shuttles. - Fixes the incorrect logic in the shuttle blueprint UI responsible for #92986. - Makes several changes to the wording of several functions of the shuttle blueprint UI in the hopes of better conveying what each button does. ## Why It's Good For The Game Fixes #92986, as well as some other issues I may not have found in my brief search. ## Changelog 🆑 fix: You no longer need 40 welding fuel to start welding or unwelding shuttle engines, despite only consuming 1. fix: Shuttle engines constructed from anchored machine frames start in the wrenched-but-unwelded state. fix: Expanding custom shuttles from shuttle frames is once again possible without href exploitation. fix: Shuttle expansion now correctly checks for other shuttle docking ports the expanded shuttle's footprint would encroach upon. qol: Tries to make some of the buttons in the custom shuttle UI more indicative of what they actually do. /🆑 |
||
|
SyncIt21andGitHub
|
2d41569c65 |
Flatpacker & machine frame enhancements (#91752)
## About The Pull Request **1. Makes the machine creation process from both efficient.** The machine frame no longer creates & deletes the machines old component parts before moving in the new parts. It instead now passes its parts directly to the circuit boards `apply_default_parts()` meaning the old parts are never created and the new ones get applied directly. This also mean it does not have to again call `RefreshParts()` as the machines `Initialize()` proc will do that for us by default so the performance is just faster now. Flatpack box also benefits from this and it will need it as stated below - Fixes #86514. As the circuit board is passed to the machine's `Initialize()` proc during reconstruction so it sets it's `all_products_free` from the board both during mapload & when player constructed from either machine frame & flatpack **2. Flatpack enhancements** - The flatpack box now passes its stored circuit board into the machine meaning any changes made like with a screw driver or such are preserved in the newly created machine rather than the board getting deleted & the machine creating the default board - Flatpacker now accept custom component parts that replaces its stored circuit board default parts. This implements https://github.com/tgstation/tgstation/pull/91670#issuecomment-2977259973 meaning instead of the vendor created from the flatpacker starting out empty it now accepts the refill canister and will package both of them together. Then during deployment that stored canister is stored back in the vendor meaning instead of starting out empty you get to carry over all your previous stock Depends on https://github.com/tgstation/tgstation/pull/91512 because of named arg conflict. Keep this drafted till that gets merged ## Changelog 🆑 qol: flatpacker now accepts custom component parts(like vendor refill canister) along with the circuit board so you can carry over your previous stock during deployment rather than starting out empty fix: flatpack boxes now passes its stored circuit board into the machine thus preserving its properties instead of creating a default board in the machine fix: vending machines reconstructed on station from circuits loaded off station(having free products) will continue to sell free products code: machine construction via flatpacker/machine frame is faster performance wise /🆑 |
||
|
SmArtKarandGitHub
|
57456921a4 |
Makes vendors created from flatpacks start empty to prevent duping (#91670)
## About The Pull Request Flatpacks pass an arg into ``on_construction`` which makes vendors wipe their inventory to prevent duping by repeatedly flatpacking a vendor to refill its inventory. Closes #91615 ## Changelog 🆑 fix: Flatpacked vendors start empty to prevent duping /🆑 |
||
|
TimandGitHub
|
cfa838fee7 |
Fix shuttle engines anchored state not matching engine_state (#91345)
## About The Pull Request Building a shuttle engine from a circuit has a misaligned state where you can weld it immediately because it thinks the engine is already anchored when it is not. This results in welded engines being able to be dragged and moved around. ## Why It's Good For The Game Bugfix. ## Changelog 🆑 fix: Fix shuttle engines built from a circuit board having it's `anchored` state not matching the correct `engine_state`. This would consider the engine to be anchored already when it was not and allow someone to weld it despite it being able to be dragged and moved around. /🆑 |
||
|
SmArtKarandGitHub
|
0dc1822cef |
Fixes escape shuttles only taking 4/9/19 minutes to arrive (#90109)
## About The Pull Request Closes #90026 ## Changelog 🆑 fix: Fixed escape shuttles only taking 4/9/19 minutes to arrive /🆑 |
||
|
Y0SH1M4S73RandGitHub
|
013de1fb80 |
Custom Shuttle QOL tweaks (and a fix to a mild shuttle engine exploit) (#89774)
## About The Pull Request This PR adds some tweaks to make custom shuttles a bit easier to use, and more useful. - The station blueprints can be used to allow/forbid custom shuttle docking in station/custom areas. Custom areas allow shuttle docking by default, while station areas (apart from the asteroid) forbid it. - A station area that allows shuttle docking can have a shuttle built/expanded in it, as long as the area's APC isn't contained within the frame used to construct/expand the shuttle. - A shuttle frame does not need to contain the entirety of a custom area, unless that frame contains the area's APC. If the frame doesn't contain the entirety of the custom area, that section of the frame becomes part of the default area, instead of a separate area. - Custom shuttles will go off into the sunset at the end of the round, as long as they have a welded engine. - I think I saw a bug that caused engines to contribute twice the intended power to the attached shuttle, possibly creating an exploit in the case where the engine was broken while welded. I fixed that. - Custom shuttle docking computers can cross over to any z-level adjacent to the shuttle's z-level (or vertically-connected z-levels, because docking computers can traverse stacked z-levels freely). This is based on the new `zlink_range` var on all shuttle docking consoles, which can be var-edited to provide the same functionality. - Shuttle engines constructed from circuits now link to shuttles without needing to be unanchored and reanchored. ## Why It's Good For The Game The tweaks to shuttle construction and docking serve to address several gripes I heard about players not being able to build/dock custom shuttles in station areas. The means to do this have been locked behind possession of the station blueprints. I don't see what problem there would be with allowing custom shuttles to leave the station at the end of the round, but I could lock it behind a particular action (antag-exclusive or otherwise). Custom shuttles don't quite have as much utility if you have to manually travel to z-levels to drop off gigabeacons. Jumping to adjacent z-levels one at a time is a bit more useful for space exploration. ## Changelog 🆑 add: The station blueprints can be used to toggle whether custom shuttles can be built/expanded/docked within station areas. qol: Custom areas do not have to be completely contained within shuttle frames, as long as the APC isn't attached to the frame. add: Custom shuttles with functioning engines will fly off into the sunset when the emergency shuttle leaves. add: Custom shuttle navigation computers can view space levels adjacent to the one the shuttle is currently docked at. fix: Constructed shuttle engines no longer contribute twice as much engine power to shuttles, nor can they be used to add unlimited shuttle power. fix: Constructed shuttle engines now connect to shuttles when build, rather than needing to be unachored and then reanchored. /🆑 |
||
|
|
cbc3350224 |
Custom Shuttles Redux: Allows for the construction of custom shuttles. (#88493)
## About The Pull Request This incredibly detailed PR adds the ability to construct custom shuttles, which function similarly to whiteships. To construct a custom shuttle, you need the following items: - Shuttle frame rods These rods can be hand-crafted by using 5 rods on 1 sheet of titanium, or printed at a sci/engi/cargo lathe after researching the Shuttle Engineering techweb node. Lattices built with these rods, and catwalks/floors built on top of these lattices, are valid for shuttle construction. - Shuttle engines Did you know shuttle engines have boards that weren't normally obtainable? Well the board for one specific engine type is now available from the sci/engi/cargo lathe after researching Shuttle Engineering. Of course, the old options remain. You can steal engines from other shuttles, including escape pods (it's not like engines are strictly necessary for *those* shuttles anyways). Alternatively, the shuttle engine supply pack is no longer locked behind the purchase of the BYOS. - Flight Control & Navigation Console boards These boards are printed at the sci/engi/cargo lathe after researching the Shuttle Engineering techweb node. If built on a custom shuttle, it will automatically link to it, unless the shuttle already has such a console. If built on a turf that is valid for custom shuttle construction, it will automatically link to any shuttle constructed from or expanded with that turf. - Shuttle blueprints Standard shuttle blueprints can be printed at the sci/engi/cargo lathe after researching the Shuttle Engineering techweb node. A cyborg upgrade granting access to a shuttle blueprint database can be printed at the exofab after researching the aforementioned node. Crude shuttle blueprints can be crafted by hand with a sheet of paper and either a rainbow crayon or 10 uses of a blue crayon or spraycan. If Science won't research the tech, you can also buy a goody pack containing a flight control board, a docker board, two engine boards, and a set of shuttle blueprints for 1200 credits, if you have aux base access. A shuttle can be constructed atop any continuous region of turfs containing a shuttle rod lattice or a catwalk/tile built upon such. Currently, this region cannot intersect any area other than space, lavaland, the icemoon, or the station asteroid. Preexisting custom areas can be included in the construction of the shuttle, but only if every turf in the custom area is valid for shuttle construction. In the shuttle blueprint UI, you can toggle a visualizer to display which turfs fulfill all of the aforementioned conditions. The following video goes through the basic process of shuttle construction. https://github.com/user-attachments/assets/3283422e-a201-4978-972d-67527b5df4ee The blueprint used to construct the shuttle will be its master blueprint. The master blueprint can be copied to other blank shuttle blueprints (or to engiborgs with the shuttle database upgrade), and allows the holder to perform a christening ritual on the shuttle to rename it. If a shuttle's master blueprint ceases to exist, a blank blueprint can be linked to the shuttle to become the new master blueprint, or an existing blueprint associated with that shuttle can be promoted to the master blueprint. Once constructed, the following options are available from the blueprint UI to modify it: - Create Area Convert a continuous open area of the shuttle into a new area with the name written in the above text input. This operates very similarly to regular area construction. - Rename Area Change the name of the area you're currently in to the name written in the above text input. - Expand Area Add a continuous open area of the shuttle to the neighboring area selected from the dropdown to the left. This operates like regular area expansion. - Expand Shuttle Expand a shuttle with valid frame turfs as defined above. These turfs must be physically connected to the shuttle. - Remove Area Remove an area, giving its tiles to the default shuttle area. - Cleanup Empty Space (implemented after the above video was recorded) Removes all completely empty turfs from the shuttle. If all the turfs in one of the shuttle's areas were removed, that area is deleted. If absolutely no turfs of the shuttle remain, the shuttle itself is deleted. Due to the ability for this action to delete the shuttle, only the master blueprint can do it. As mentioned above, the shuttle's master blueprint can be used to christen its associated shuttle. To do this, fill a glass drink bottle with some amount of reagents, then hit it against one of the shuttle's walls from outside while holding the master blueprint. You will be prompted to enter a new name for the shuttle. The variety of things that can happen while inputting a new name can cause the christening rite to fail in one of several humorous ways. ### Optional (Unless specifically requested by a maintainer) Todo's - [x] A way for shuttle circuits to be obtainable without techweb nodes - [x] A more convenient way to carry around shuttle engines or the means to deploy them - [ ] A shuttle construction guide available as a reference book - [ ] Allow boards to be linked to shuttles before construction so they can be used outside the shuttle ## Why It's Good For The Game Shuttles have been part of the sandbox for an incredibly long time, but their limited accessibility has rendered them the exclusive territory of lucky space explorers or the few antagonists who get one off the bat (nukies and pirates). Giving players the means to construct shuttles to their liking opens up a variety of possibilities for gimmicks for antags and non-antags alike. Besides the applications for antaggery and crew-sided gimmicks, this provides side content for several departments to engage with during the relatively-frequent periods of time where they have little else to do as part of their intended roles. With respect to engineering, if the station isn't actively being damaged, the supermatter is in perfect working order, and nobody is clamoring for machine upgrades, engineers have little else to resort to other than construction projects. While the BSA station goal provides an incentive for engineers to construct dedicated rooms for the cannon, it will not necessarily be available every round. Custom shuttles not only provide such a construction project to pursue, but provide the rare opportunity, as well as a very good reason, to set up an independent power network, complete with its own power source. While atmos techs have a lot to do with gas mixing and the crystallizer, they rarely get the opportunity to set up working life support systems outside of repairing the ones that get blown up. Custom shuttles will frequently start with no air, and unless the design settled upon is an open floor plan, it will have several independent chambers that cannot so easily be profused with a proper airmix by just opening a canister. Furthermore, if the air in a custom shuttle gets messed up, a proper scrubber and distro network is a significantly less tedious method of rectifying the problem than cleaning the air manually with portable scrubbers and pumps. Scientists, it can be argued, with their access to RPDs through ordnance, have similar opportunities to atmos techs, even though the act in and of itself is not exactly part of their duties. But compared to the other job content they could be working with after they've completed most of their gameplay loop, custom shuttle construction is a substantially more active endeavor. And I know how much people complain about late-game science content just being sitting around at a console and making gamer gear. Roboticists can have a part to play in this too. They can put their mech RCDs to a use other than 2D topdown Fortnite, and with the shuttle database upgrade, they can help interested cyborgs get in on the action. Cargo is yet another department known for having significant amounts of downtime during a considerable number of rounds. If every other department has gone through their initial rounds of departmental orders, and there isn't an active need for cargo to order lots of one thing or another, cargo techs have little to do besides mail (at least on the days where there **is** mail to deliver). Usually, if cargo techs do, in fact, do something as a department when not presented with more pressing duties, they order guns and other contraband. As funny as this is, there's not a lot of variety in how this behavior manifests. With custom shuttles, cargo can use their free time to plan, and execute, a unique collective expression of design sensibilities, not limited by the size and shape constraints of the cargo bay itself. ## Changelog 🆑 Y0SH1_M4S73R (with special thanks to Vect0r, whose original PR inspired the implementation of these changes) add: Shuttle blueprints, the tool used to construct and modify custom shuttles. Print a set at a science, engineering, or cargo techfab after researching Shuttle Engineering, or craft a crude set from the crafting menu. add: Shuttle blueprint database upgrade for engineering cyborgs, printable from the Exosuit Fabricator after researching Shuttle Engineering. A version of shuttle blueprints designed for use by cyborgs. add: Shuttle frame rods, usable to construct custom shuttles. Hand-craft by using 5 rods on 1 titanium sheet, or by printing them at a science, engineering, or cargo techfab after researching Shuttle Engineering. add: Custom shuttle flight control and navigation boards, printable from a science, engineering, or cargo techfab after researching Shuttle Engineering. add: Shuttle engine boards can be printed from a science, engineering, or cargo techfab after researching shuttle engineering. add: The shuttle engine supply pack is no longer locked behind the purchase of the Build Your Own Shuttle kit. add: Shuttle Construction Starter Kit goodie pack, containing a set of shuttle blueprints, flight control and navigation console boards, and two engine boards, can be purchased from cargo for 1200 credits. Requires aux base access to purchase. refactor: Shuttles now keep track of what areas are underneath each of their individual turfs, so that the areas left behind on movement are consistent with what they were beforehand. refactor: Shuttle ceilings now place themselves down as baseturfs, instead of only appearing if the turf above is open space. /🆑 --------- Co-authored-by: vect0r <71346830+Vect0r2@users.noreply.github.com> Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com> Co-authored-by: necromanceranne <40847847+necromanceranne@users.noreply.github.com> |
||
|
Penelope HazeandGitHub
|
d0a7f955f8 |
Fix various issues with names in string interpolation (#89246)
## About The Pull Request Commit messages should be descriptive of all changes. The "incorrect `\The` macro capitalization" was intentional when it was added, but as far as I know TG says "the supermatter" rather than "The Supermatter," so it's incorrect now. This is completely untested. I don't even know how you'd go about testing this, it's just a fuckton of strings. Someday I want to extract them and run NLP on it to catch grammar problems... ## Why It's Good For The Game Basic grammar pass for name strings. Should make `\the` work better and avoid cases like `the John Smith`. |
||
|
|
a4e7929a3b |
Lighters use welding fuel and can be used as welders in some cases (#85941)
## About The Pull Request Lighters now have welding fuel which can be filled/extracted by hand, giving a small but consistent source of welding fuel for non-chemists. Welding fuel is now required for these lighters to work, they'll close automatically once they're out of fuel. They last for a minute, zippo lasts 2 minutes, before they need to be refuelled. It can have other reagents put into it but it only checks for welding fuel, so it won't work at all unless its got some. They can be used as welding tools in minor cases, mostly fixing things and welding doors shut, but can't do big things like deconstruction, except the xenobio one because it's a lot hotter than the normal lighter. Also added a baseline support to check for heat to perform certain welds, before heat is just this binary "has or doesnt have heat", which made its value useless. ## Why It's Good For The Game Adds a ghetto way of getting welding fuel, hiding reagents, and a ghetto welding tool without being something that prisoners could break out of prison with. They could weld the doors shut which is a little funny, security still has proper welding tools to counter it. It also currently is kinda lame that lighters could just be open 24/7, unlike matches which has a lifespan of 10 seconds each or something. ## Changelog 🆑 add: Lighters now use and require welding fuel to work, but can be used as a welding tool for tasks that don't require much heat. /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
tgstation-ci[bot]GitHubtgstation-ci <179393467+tgstation-ci[bot]@users.noreply.github.com>Jordan DominionGhomsan7890MrMelbert |
9a9b428b61 |
Wallening Revert [MDB Ignore][IDB Ignore] (#86161)
This PR is reverting the wallening by reverting everything up to
|
||
|
+16
|
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> |
||
|
MrMelbertandGitHub
|
1e76fd70b4 |
Attack chain refactoring: Broadening tool_act into item_interact, moving some item interactions to... atom/item_interact / item/interact_with_atom (#79968)
## About The Pull Request Implements half of this (with some minor changes):  The ultimate goal of this is to split our attack chain in two: - One for non-combat item interactions - Health analyzer scanning - using tools on stuff - surgery - Niche other interactions - One for combat attacking - Item hit thing, item deal damage. - Special effects on attack would go here. This PR begins this by broadining tool act into item interact. Item interact is a catch-all proc ran at the beginning of attack chain, before `pre_attack` and such, that handles the first part of the chain. This allows us to easily catch item interaction and cancel the attack part of the chain by using deliberate bitflag return values, rather than `TRUE` / `FALSE`*. *Because right now, `TRUE` = `cancel attack`, no matter what, which is unclear to people. Instead of moving as much as possible to the new proc in this PR, I started by doing some easy, obvious things. More things can be moved in the future, or technically they don't even need to move in a lot of cases. ## Changelog 🆑 Melbert refactor: Refactored some methods of items interacting with other objects or mobs, such as surgery and health analzyers. Report if anything seems wrong /🆑 |
||
|
ArcaneMusicandGitHub
|
04fdcf1f6b |
Shuttle engines screentips and better examine (#78255)
## About The Pull Request Shuttle engines now tell you how to install them based on what tool is necessary to progress to the next step. This information is included in the examine text of the engine, as well as giving proper screentips when holding the correct tools. ## Why It's Good For The Game Improves visual clarity on otherwise VERY hard to determine information. The installation steps for the engine are literally nowhere in the game so you are required to code dive to find out. ## Changelog 🆑 qol: Shuttle engines now tell you how to install them in their screentips and their examine text. /🆑 |
||
|
YesterdaysPromiseandGitHub
|
fb10121022 |
Icons folder cleaning wave two (#76788)
## About The Pull Request Further continous organizing and cleaning the Icons folder. There are still some minior nitpicks left to do, but I reached my daily sanity expenses limit again, and the faster these get in the less issues for both me and others later. Also cleans some mess I caused by my blindness last PR. ## Why It's Good For The Game Saner spriters = better sprites |
||
|
CoulsandGitHub
|
c0e46fabf7 |
Standardize Welder Fuel Usage (#76021)
Remove welder fuel usage from all actions except attacking and leaving it on most welder tasks require a minimum of 1u of fuel, some longer tasks require a minimum of 2 or 3u welders now drain 1u every 5 seconds they're active ## About The Pull Request Prior to this PR welder fuel usage was random, a lot of tasks didn't use any welder fuel and welders were basically near infinite so long as you didn't use them for combat, it took 26 seconds of activity to drain 1u of fuel, that means an emergency welder alone could run for 5 minutes straight before needing a refuel After this PR all welders will drain 1u every 5 seconds instead of every 26 seconds, but welding objects won't require extra fuel anymore, making the fuel usage much more consistent. resolves #55018 ## Why It's Good For The Game Actually makes fuel tanks useful and relevant without making it obnoxious to do repetitive quick tasks like turn rods into plates, there's actually a reason to upgrade off the emergency welder now since it lasts 50 seconds rather than 5 minutes ## Changelog 🆑 qol: Welders now have a more consistent fuel usage /🆑 |
||
|
|
72add64520 |
Refactors armor into dedicated subtypes (#71986)
## About The Pull Request See title. ## Why It's Good For The Game Code is cleaner, and more readable/intuitive Technically closes https://github.com/tgstation/dev-cycles-initiative/issues/8 ## Changelog 🆑 refactor: armor, from the ground up basically /🆑 Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
MothblocksandGitHub
|
75439c71f2 |
Smoothing groups optimization, save 265ms with configs, more on production & w/ space ruins (#71989)
This one is fun. On every /turf/Initialize and /atom/Initialize, we try to set `smoothing_groups` and `canSmoothWith` to a cached list of bitfields. At the type level, these are specified as lists of IDs, which are then `Join`ed in Initialize, and retrieved from the cache (or built from there). The problem is that the cache only misses about 60 times, but the cache hits more than a hundred thousand times. This means we eat the cost of `Join` (which is very very slow, because strings + BYOND), as well as the preliminary `length` checks, for every single atom. Furthermore, as you might remember, if you have any list variable set on a type, it'll create a hidden `(init)` proc to create the list. On turfs, that costs us about 60ms. This PR does a cool trick where we can completely eliminate the `Join` *and* the lists at the cost of a little more work when building the cache. The trick is that we replace the current type definitions with this: ```patch - smoothing_groups = list(SMOOTH_GROUP_TURF_OPEN, SMOOTH_GROUP_FLOOR_ASH) - canSmoothWith = list(SMOOTH_GROUP_FLOOR_ASH, SMOOTH_GROUP_CLOSED_TURFS) + smoothing_groups = SMOOTH_GROUP_TURF_OPEN + SMOOTH_GROUP_FLOOR_ASH + canSmoothWith = SMOOTH_GROUP_FLOOR_ASH + SMOOTH_GROUP_CLOSED_TURFS ``` These defines, instead of being numbers, are now segments of a string, delimited by commas. For instance, if ASH used to be 13, and CLOSED_TURFS used to be 37, this used to equal `list(13, 37)`. Now, it equals `"13,37,"`. Then, when the cache misses, we take that string, and treat it as part of a JSON list, and decode it from there. Meaning: ```java // Starting value "13,37," // We have a trailing comma, so add a dummy value "13,37,0" // Make it an array "[13,37,0]" // Decode list(13, 37, 0) // Chop off the dummy value list(13, 37) // Done! ``` This on its own eliminates 265ms *without space ruins*, with the combined savings of turf/Initialize, atom/Initialize, and the hidden (init) procs that no longer exist. Furthermore, there's some other fun stuff we gain from this approach emergently. We previously had a difference between `S_TURF` and `S_OBJ`. The idea is that if you have any smoothing groups with `S_OBJ`, then you will gain the `SMOOTH_OBJ` bitflag (though note to self, I need to check that the cost of adding this is actually worth it). This is achieved by the fact that `S_OBJ` simply takes the last turf, and adds onto that, meaning that if the biggest value in the sorting groups is greater than that, then we know we're going to be smoothing to objects. This new method provides a limitation here. BYOND has no way of converting a number to a string at compile time, meaning that we can't evaluate `MAX_S_TURF + offset` into a string. Instead, in order to preserve the nice UX, `S_OBJ` now instead opts to make the numbers negative. This means that what used to be something like: ```dm smoothing_groups = list(SMOOTH_GROUP_ALIEN_RESIN, SMOOTH_GROUP_ALIEN_WEEDS) ``` ...which may have been represented as ```dm smoothing_groups = list(15, MAX_S_TURF + 3) ``` ...will now become, at compile time: ```dm smoothing_groups = "15,-3," ``` Except! Because we guarantee smoothing groups are sorted through unit testing, this is actually going to look like: ```dm smoothing_groups = "-3,15," ``` Meaning that we can now check if we're smoothing with objects just by checking if `smoothing_groups[1] == "-"`, as that's the only way that is possible. Neat! Furthermore, though much simpler, what used to be `if (length(smoothing_groups))` (and canSmoothWith) on every single atom/Initialize and turf/Initialize can now be `if (smoothing_groups)`, since empty strings are falsy. `length` is about 15% slower than doing nothing, so in procs as hot as this, this gives some nice gains just on its own. For developers, very little changes. Instead of using `list`, you now use `+`. The order might change, as `S_OBJ` now needs to come first, but unit tests will catch you if you mess up. Also, you will notice that all `S_OBJ` have been increased by one. This is because we used to have `S_TURF(0)` and `S_OBJ(0)`, but with this new trick, -0 == 0, and so they conflicted and needed to be changed. |
||
|
John WillardandGitHub
|
422accbe4e |
[MDB IGNORE] Shuttle engines part 2: Engines are now machines (#69793)
* Makes engines machines instead of structures * Updates the maps * Fixes boards and anchoring * Removes 2 unused engine types Router was actually used a total of once, so I just replaced it with propulsion. I think cutting down on these useless engine types that make no difference in-game would be a nice first step to adding more functionalities to them. * Don't use power (since shuttles dont have) Shuttles don't have APCs, instead they just have infinite power, so I'm removing their power usage for now. I'm hoping this can be removed when unique mechanics are added to engines, because I would like them to make use of power like other machines. * re-organizes vars * deletes deleted dm file * Slightly improves cargo selling code * Renames the updatepaths * Removes in_wall engines I hate this stupid engine it sucks it's useless it's used solely for the tram it provides nothing of benefit to the server replaces them with regular engines |
||
|
John WillardandGitHub
|
2e771d6c48 |
Fixes inconsistencies in engine thrust (#69826)
current_engines and initial_engines were actually their thrust power, which I was unaware of because of undocumented vars. I renamed the, documented them, and fixed them. |
||
|
|
253613c1c3 |
[MDB IGNORE] Shuttle engine code improvement and fixes (#69516)
* A lot of shuttle code improvements * Makes use of ``as anything`` in many places * Adds mapload to connect_to_shuttle() * Renames many vars, including shuttle 'id' var to 'shuttle_id' and engine 'state' to 'engine_state'. * Engines now weakref their attached ship, and disconnect when unwrenched from it. * Removes check for force when deleting a mobile docking port, being deleted should still clear your stuff, regardless of being forced. Because of all the above, I was able to remove a few pointless checks scattered around, like engine's alter_engine_power() * better comment for port_id * Fixes Cargo, Arrivals, and Pirate ships. * Merge branch 'master' into shuttlecode-oh-no * last few * fixes the CI * fixes * Fixes infinite engines * Revert "Merge branch 'master' into shuttlecode-oh-no" This reverts commit 94eba37de9fe3f4a01dc40bb064771b764f379e3. * trammies * whiteship tram * Makes use of ?. instead apparently this is what weakrefs use, so 🤷 * i hate supernovaa41 Co-authored-by: Seth Scherer <supernovaa41@gmx.com> * removes lateinit that I never implemented * adds _ref to weakref var name * small change to weld time define Co-authored-by: Seth Scherer <supernovaa41@gmx.com> |
||
|
LemonInTheDarkandGitHub
|
98f32035d8 |
Parallax but better: Smooth movement cleanup (#66567)
* Alright, so I'm optimizing parallax code so I can justify making it do a
bit more work
To that end, lets make the checks it does each process event based.
There's two. One is for a difference in view, which is an easy fix since
I added a view setter like a year back now.
The second is something planets do when you change your z level.
This gets more complicated, because we're "owned" by a client.
So the only real pattern we can use to hook into the client's mob's
movement is something like connect_loc_behalf.
So, I've made connect_mob_behalf. Fuck you.
This saves a proc call and some redundant logic
* Fixes random parallax stuttering
Ok so this is kinda a weird one but hear me out.
Parallax has this concept of "direction" that some areas use, mostly
the shuttle transit ones. Set when you move into a new area.
So of course it has a setter. If you pass it a direction that it doesn't
already have, it'll start up the movement animation, and disable normal
parallax for a bit to give it some time to get going.
This var is typically set to 0.
The problem is we were setting /area/space's direction to null in
shuttle movement code, because of a forgotten proc arg.
Null is of course different then 0, so this would trigger a halt in
parallax processing.
This causes a lot of strange stutters in parallax, mostly when you're
moving between nearspace and space. It looks really bad, and I'm a bit
suprised none noticed.
I've fixed it, and added a default arg to the setter to prevent this
class of issue in future. Things look a good bit nicer this way
* Adds animation back to parallax
Ok so like, I know this was removed and "none could tell" and whatever,
and in fairness this animation method is a bit crummy.
What we really want to do is eliminate "halts" and "jumps" in the
parallax moveemnt. So it should be smooth.
As it is on live now, this just isn't what happens, you get jumping
between offsets. Looks frankly, horrible. Especially on the station.
Just what I've done won't be enough however, because what we need to do
is match our parallax scroll speed with our current glide speed. I need
to figure out how to do this well, and I have a feeling it will involve
some system of managing glide sources.
Anyway for now the animation looks really nice for ghosts with default
(high) settings, since they share the same delay.
I've done some refactoring to how old animation code worked pre (
|
||
|
FikouandGitHub
|
37eea8e19d |
[Ready] Hilbert Research Facility remap feat. tram (#66082)
* reworks hilbert's hotel ruin * warooio * you can now run multiple trams on the same z at the same time, trams are linked by id * fuck * sure * you are a simulacra * FUG * dock |
||
|
|
2db00c7dc5 |
standardizes default unfasten wrench (#65425)
I'll do more in the future but I'll limit myself to this because I'm tired, bored, and don't want to make so many PRs touching the same things that I have to deal with conflicts each time one is merged. Just as an example, screwdriver's gotta be done as well, does the exact same thing wrenches do, I believe. Standardizes (and touches) each time default_unfasten_wrench is used. Fixes tool logs, since it relies on tool acts to exist, I'm trying to move as many tool acts to its proper proc. Like a spiritual successor to the tool superpack PRs. Co-authored-by: Luc <89928798+lewcc@users.noreply.github.com> |
||
|
小月猫andGitHub
|
b757fce02a |
New in-wall engine sprites (#64839)
adds new variants for each sized engine to look like they are in walls (basically cut down sprites with their density set to false (because they dont take up the full tiles, especially the huge engines are 3x3 but only take up 1x3, they must have no density or they block way more than they should)) before: dumb looking gap image after: nice clean engine (and box trams are soul filled, also, trams kinda too small to really get any sort of diagnal design working) image showcase of each sized thruster: image added new structures that act like walls but arent turfs, and can only be used (and can be used!) on trams! comes with 3 types, iron, plastitanium, and titanium. supports more types being added if you want but these are basically all that a tram needs to use: Untitled.1.mp4 also removed a duplicated APC in a maint on tram, and removed cycle helpers from random maint airlocks that arent actually meant to cycle (they are solo) Why It's Good For The Game engines are kinda too bulky and organically shaped so they dont really fit some designs such as tram as a good example, in wall designs allow you to add thrusters onto any shaped ship easily without worrying about ensuring the walls around them being shaped right, as it appears to have the bulk of the engine merged inside the wall Changelog cl Nari Harimoto imageadd: New thruster sprites to allow for in-wall designs fix: removed cycle helpers from 2 random tram maint airlocks that arent meant to cycle (solo airlocks) and a duplicated APC in tram maint expansion: the tram now has new walls! they are structures that function like walls so as to be built on the tram, create and deconstruct via the new tram girder (screwdriver on the girder to deconstruct, there is no displaced version ie wrench) /cl |
||
|
MothblocksandGitHub
|
0f3c4e51f7 |
Modernizing Radiation -- TL;DR: Radiation is now a status effect healed by tox healing, and contamination is removed (#62265)
Implements the Modernizing radiation design document ( https://hackmd.io/@tgstation/rJNIyeBHt ) and replaces the current radiation sources with the new system, as well as replacing/removing a bunch of old consumers of radiation that either had no reason to exist, or could be replaced by something else. Diverges from the doc in that items radiation don't go up like explained. I was going to, but items get irradiated so easily that it just feels pretty lame. Items still get irradiated, but it's mostly just so that radiation sources look cooler (wow, lots of stuff around going green), and for things like the geiger counter. Instead of the complicated radiation_wave system, radiation now just checks everything between the radiation source and the potential target, losing power along the way based on the radiation insulation of whats in between. If this reaches too low a point (specified by radiation_pulse consumers), then the radiation will not pass. Otherwise, will roll a chance to irradiate. Uranium structures allow a delay before irradiating, so stay away! |
||
|
GhilkerandGitHub
|
cb5fb1df2d |
modules/atmospherics major cleanup (#61904)
major cleanup of modules/atmospherics folder and all related files, still many missing -cleanup of procs name -cleanup of vars name -documentation of some of the procs -minor changes to some for() logic (no in game changes just early continue or as anything checks) No in game changes, only code and docs |
||
|
Watermelon914andGitHub
|
375a20e49b |
Refactors most spans into span procs (#59645)
Converts most spans into span procs. Mostly used regex for this and sorted out any compile time errors afterwards so there could be some bugs. Was initially going to do defines, but ninja said to make it into a proc, and if there's any overhead, they can easily be changed to defines. Makes it easier to control the formatting and prevents typos when creating spans as it'll runtime if you misspell instead of silently failing. Reduces the code you need to write when writing spans, as you don't need to close the span as that's automatically handled by the proc. (Note from Lemon: This should be converted to defines once we update the minimum version to 514. Didn't do it now because byond pain and such) |
||
|
TemporalOroborosandGitHub
|
6e950daccc | Defines damage flags. (#53158) | ||
|
RohesieandGitHub
|
25f670f8de |
Opacity refactor (#52881)
Moves all opacity var manipulation to a proc which sends a signal.
light_blocker element for movable opaque atoms made, which tracks its movement and updates the affected turfs for proper lighting updates.
has_opaque_atom boolean replaced by the opacity_sources lazylist to keep track of the sources, and a directional_opacity which serves a similar function but also allows for future expansion with on-border opaque objects (not yet implemented).
Some opacity-related sight procs optimized as a result of this.
Some variables moved to the object's definition.
A define or two added into the mix for clarity.
Some code cleaning, like turning booleans into their defines.
One file renamed for clarity.
Changelog
cl
balance: Mechs no longer block sight. It's a non-trivial cost for the lighting system with little to no gain.
/cl
|
||
|
FikouandGitHub
|
cc9945b8a4 | shuttle parts are now in shuttle part smoothing group (#53015) | ||
|
RohesieandGitHub
|
d117e18882 | shuttle density (#52914) | ||
|
|
62676e72a8 |
Force LF line endings with gitattributes and convert repo (#52266)
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com> |
||
|
kingofkosmosandRob Bailey
|
8358169b8e |
New 'hear' span class (#46369)
* Reverts italics-span back to no color. * Cleans up many extra spaces and indents. * Adds 'hear' span class. * Replaces all 'italics' used in heard messages with 'hear'. |
||
|
kingofkosmosandoranges
|
df1fecc58c |
Adds notice-span to visible_messages with no spans (#46044)
About The Pull Request Adds 'notice' span class to all visible_messages which had no span class, making all those black messages blue. Why It's Good For The Game This should help differentiate action-messages from talking-messages in the chat. More actions will be blue, thus black talking-messages should pop out more. |
||
|
nemvarandRob Bailey
|
e587b970da |
Adds parent calls to almost all tool_acts (#45582)
* Adds parent calls to almost all tool_acts * actually compiles |
||
|
Emmett GainesandShizCalev
|
6faf6e8d78 | Updates the engine heater sprite so it's obvious they don't block air (#38998) | ||
|
Denton
|
2eb8801397 |
Stops engine heaters from passing atmos
sfdsfdsfdfs |
||
|
ShizCalevandTad Hardesty
|
c41d6ac965 |
Standardizes and cleans up some admin messages & logging (#38128)
* Improved logging * Fixes & emitter logging * ded |
||
|
ACCount12
|
1621f37a8c | Ports some operation to tool_act | ||
|
Jordan BrownandShizCalev
|
d282c60c7d | Quote the armor lists (#35668) | ||
|
ACCountandAnturK
|
100c4b6114 |
Adds new helper: use_tool, shakes things up in tool code (#35095)
* small changes * Adds a use_tool helper and changes some tools to use it * Ports most tool operations to use_tool * Converts more tool operations to use_tool and tool_act * Changes some things to default_unfasten_wrench * Improves tool_behavior support in mech construction * Code review memes * Fixes all instant use_tool calls failing * Code improvements * merge fixes |
||
|
bawhoppenandoranges
|
3e4d747b77 |
Adds desc to things lacking them. (#31086)
* Desc change * Update girders.dm * Update valve.dm * Update machine_stacking.dm * Update shuttle_engines.dm * Update pipe_dispenser.dm * Update lib_items.dm |
||
|
Jordan BrownandLeo
|
af4d9a85c9 | Repaths /obj/item/weapon to /obj/item (#29929) | ||
|
Joan Lung
|
1feb0021a1 | Removes now-unnecessary obj_integrity definitions | ||
|
AnturKandLeo
|
0c3edf1ff7 | Shuttle engines affecting travel time (#28564) | ||
|
ShizCalevandLeo
|
ca29c6c510 | Varedit cleanup: Mk 4½ (#28715) | ||
|
WJohnandRemie Richards
|
5c3b433489 |
New syndicate cosmetics, turfs, and spawners. (#27760)
* Loads of syndicate battlecruiser related content. Clothing, turfs, areas, and a few mob spawners. * Moves new plaque turfs and all other ones to a new plaques dmi. * does what joan asked * whoops forgot to add some dmis and delete one * Adds syndicate energy turrets. * PROBABLY STILL OKAY * Unticks file dir? * Forgot to remove extra sprites in shuttles.dmi since they're now in proper dmis of their own in full size. |
||
|
phil235andoranges
|
5f835bfc26 |
Obj damaging system, acid damage, and fire damage refactor (WIP) (#20793)
Please refer to #20867 and #20870 for a easier view of the changes. Those two PRs show all meaningful changes (hopefully) and doesn't show the files changed with just 3 lines changed. This PR does three things: It makes all children of /obj/ use the same damage system. Previously to make your new machine/structure be destroyable you needed to give it a var/health, and its own version of many damage related proc such as bullet_act(), take_damage(), attacked_by(), attack_animal(), attack_hulk(), ex_act(), etc... But now, all /obj/ use the same version of those procs at the /obj/ level in code/game/obj_defense.dm. All these obj share the same necessary vars: obj_integrity (health), max_integrity, integrity_failure (optional, below that health level failure happens), and the armor list var which was previously only for items, as well as the resistance_flags bitfield. When you want your new object to be destroyable, you only have to give it a value for those vars and maybe override one proc if you want a special behavior but that's it. This reorganization removes a lot of copypasta (most bullet_act() version for each obj were nearly identical). Two new elements are added to the armor list var: fire and acid armor values. How much damage an obj take depends on the armor value for each damage category. But some objects are INDESTRUCTIBLE and simply never take any damage no matter the type. The armor categories are: -melee(punches, item attacks, xeno/animal/hulk attacks, blob attacks, thrown weapons) -bullet -laser -energy (used by projectiles like ionrifle, taser, and also by EMPs) -bio (unused for this, only here because clothes use them when worn) -rad (same) -bomb (self-explanatory) -fire (for fire damage, not for heat damage though) -acid For machines and structures, when their health reaches zero the object is not just deleted but gets somewhat forcedeconstructed (the proc used is shared with the actual deconstruction system) which can drops things. To not frustrates players most of these objects drop most of the elements necessary to rebuild them (think window dropping shards). Machines drop a machine frame and all components for example (but the frame can then be itself smashed to pieces). For clothes, when they are damaged, they get a "damaged" overlay, which can also be seen when worn, similar to the "bloody" overlay. It refactors acid. See #20537. Some objects are ACID_PROOF and take no damage from acid, while others take varying amounts of damage depending on their acid armor value. Some objects are even UNACIDABLE, no acid effect can even land on them. Acid on objects can be washed off using water. It changes some aspect of damage from fires. All /obj/ can now take fire damage and be flammable, instead of just items. And instead of having just FLAMMABLE objs that become ON_FIRE as soon as some fire touch them (paper), we now have objects that are non flammable but do take damage from fire and become ashes if their health reaches zero (only for items). The damage taken varies depending on the obj's fire armor value and total health. There's also still obj and items that are FIRE_PROOF (although some might still be melted by lava if they're not LAVA_PROOF). When a mob is on fire, its clothes now take fire damage and can turn to ashes. Similarly, when a mob takes melee damages, its clothes gets damaged a bit and can turn to shreds. You can repair clothes with cloth that is produceable by botany's biogenerator. It also does many minor things: Clicking a structure/machine with an item on help intent never results in an attack (so you don't destroy a structure while trying to figure out which tool to use). I moved a lot of objects away from /obj/effect, it should only be used for visual effects, decals and stuff, not for things you can hit and destroy. I tweaked a bit how clothes shredding from bombs work. I made a machine or structure un/anchorable with the wrench, I don't remember which object... Since I changed the meaning of the FIRE_PROOF bitflag to actually mean fire immune, I'm buffing the slime extract that you apply on items to make them fire proof. well now they're really 100% fire proof! animals with environment_smash = 1 no longer one-hit destroy tables and stuff, we give them a decent obj_damage value so they can destroy most obj relatively fast depending on the animal. Probably a million things I forgot. If you want to know how the damage system works all you need is the three obj vars "obj_integrity", "max_integrity", "integrity_failure", as well as the armor list var and the resistance_flags bitfield, and read the file obj_defense.dm |