mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-13 17:14:47 +01:00
observer_fix_tm
127 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 FalloutFalcon
|
aa8e9aaf94 |
Lattice ignore slowdown of turf and stop immersive overlay from water (#94199)
## About The Pull Request first part is prob a balance thing but the immersive part feels like an oversight. Current behavior (catwalks already have both the traits im adding) https://github.com/user-attachments/assets/2f1b44f3-5942-4e54-9e9a-c6ae9b9bde9e ## Why It's Good For The Game For the immersive part, it looks bad as its half submersed yet you also sink just as much despite it feeling like something you would stand on. For a similar logic, lattice seem like something you should be able to walk ontop of. thus ignoring the slowdown of the turf underneath it. It stops you from falling into both chasms and hyperspace. It would likely stop you from dredging through mud or similar turfs that have slowdown |
||
|
Bloop
|
9c8a60a0b8 |
Removes some cargo cult string interpolations (#94210)
## About The Pull Request Macros that are strings do not need to be doing this. ## Why It's Good For The Game Less improper things to copy paste existing in the codebase |
||
|
Tim
|
469c32c64d |
Fix lattice deconstruction to update space areas (#93971)
## About The Pull Request When lattice and catwalks are deconstructed on `/area/space/nearstation` the area should update to `/area/space` since it is now an empty space tile. ## Why It's Good For The Game Consistency. This is very noticeable when exporting maps and there are chunks of nearstation area markers with empty space. ## Changelog 🆑 fix: Fix lattice deconstruction to update space areas /🆑 |
||
|
SmArtKar
|
49c373da34 |
Resprites boulder platforms and adds smoothing to them (#93588)
## About The Pull Request Changes platforms to a more topdown perspective to be in line with lava turfs and adds smoothing to them, ensuring that they always take up all the space on their lava tile but don't go onto basalt <img width="860" height="653" alt="dreamseeker_07DHZsrM1C" src="https://github.com/user-attachments/assets/4522d3e4-27e0-4866-aa07-93d7eeb0f5e1" /> ## Why It's Good For The Game Currently large sections of platforms look a bit jank, as can be seen in the original vent platform PR <img width="923" height="784" alt="489234293-9c222c28-f63a-4955-b4b4-c600e934c0c9" src="https://github.com/user-attachments/assets/91b32618-2496-494e-ac3e-737d8ca999cc" /> This should make it much easier to discern which tiles are safe to step on during hectic combat of vent defense ## Changelog 🆑 image: Boulder platforms spawned by throwing boulders on lava or activating vents now have new sprites that smooth together /🆑 |
||
|
MrMelbert
|
750ca9d2ec | Two as anything greps (and some other cleanup) (#92974) | ||
|
Hatterhat
|
ea06f858c8 |
repaths lava lattices to lava catwalks (#92994)
Co-authored-by: Hatterhat <Hatterhat@users.noreply.github.com> |
||
|
SimplyLogan
|
f56811d8de |
Fixes unable to place power cables on reinforced catwalk in Lavaland (#93033)
<img width="443" height="217" alt="image" src="https://github.com/user-attachments/assets/70968561-5ce4-44d2-b731-fcde46728881" /> <img width="288" height="143" alt="image" src="https://github.com/user-attachments/assets/8d4784ef-25d7-4fc5-88e4-2dbadce71623" /> ## About The Pull Request Great success for #92975 resistance_flags = INDESTRUCTIBLE Prevented cables being placed on that reinforced catwalk Allowed just cables to be placed but the things are still unable to be damaged in testing I also made sure it does not affect regular catwalks | Cannot place cables still | Need to remove cover | |--------|--------| | <img width="183" height="366" alt="image" src="https://github.com/user-attachments/assets/d3a3704f-25ed-4567-85eb-e058aa1071fc" /> | <img width="189" height="362" alt="image" src="https://github.com/user-attachments/assets/80c73a19-d699-4a91-89f2-77e3c4434ed7" />| ## Why It's Good For The Game - Allows you to fix wire / power issues on Lavaland ## Changelog 🆑 fix: Fixes unable to place power cables on reinforced catwalk in Lavaland /🆑 Co-authored-by: loganuk <falseemail@aol.com> |
||
|
ArcaneMusic
|
985fac79eb | Boulders can now be used on lava turfs in order to create temporary, walkable platforms (#92877) | ||
|
MrMelbert
|
5261efb67f |
Re-refactors batons / Refactors attack chain force modifiers (#90809)
## About The Pull Request Melee attack chain now has a list passed along with it, `attack_modifiers`, which you can stick force modifiers to change the resulting attack This is basically a soft implementation of damage packets until a more definitive pr, but one that only applies to item attack chain, and not unarmed attacks. This change was done to facilitate a baton refactor - batons no longer hack together their own attack chain, and are now integrated straight into the real attack chain. This refactor itself was done because batons don't send any attack signals, which has been annoying in the past (for swing combat). ## Changelog 🆑 Melbert refactor: Batons have been refactored again. Baton stuns now properly count as an attack, when before it was a nothing. Report any oddities, particularly in regards to harmbatonning vs normal batonning. refactor: The method of adjusting item damage mid-attack has been refactored - some affected items include the Nullblade and knives. Report any strange happenings with damage numbers. refactor: A few objects have been moved to the new interaction chain - records consoles, mawed crucible, alien weeds and space vines, hedges, restaurant portals, and some mobs - to name a few. fix: Spears only deal bonus damage against secure lockers, not all closet types (including crates) /🆑 |
||
|
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. /🆑 |
||
|
SmArtKar
|
b626509622 |
[MDB IGNORE] Implements an automatic nearstation area tiler (#90660)
## About The Pull Request Space turfs will now assign the nearspace area to themselves whenever they're replaced, or lattice or catwalks are placed ontop of them. This fixes lighting missing from player-created space structures until they create a custom area, and resolves a similar issue with shuttle ceilings. To track this we had ceilings spawn the "shit be fucked" marker whenever they were created outside of nearspace, which is now gone. Shuttles bypass this autotiler for non-space areas, because they'd replace it anyways. **This does not work on mapload to cut down on init times**, mappers still have to place nearstation areas on their maps where they place some sort of a structure in space. They do not have to do this for shuttle landing areas now, however. Closes #84597 ## Why It's Good For The Game Shit be fucked markers created by ceilings are a god awful solution because we have player-controlled shuttles with custom positioning, so every time you moved a shuttle to a bottom level of any multiz map, you get a bunch of them on your shuttle's roof. ## Changelog 🆑 fix: Fixed "shit be fucked" errors and missing lighting on shuttle ceilings docked to bottom z levels of multiz maps /🆑 |
||
|
Bloop
|
e485bf632b |
Stops spurious ruins lattice CI runtimes (#89890)
## About The Pull Request Simply stops this from `stack_trace()`'ing in ruins, opting to `log_mapping()` instead. By changing it to use `log_mapping()` it will only cause CI failures if they occur on mining or station z levels, which should stop ruins weirdness from causing garbage outputs/failures in tests. As well as improving the debug logging by adding the area to the printout. ## Why It's Good For The Game There's really no point to complaining about a ruin spawning overlapping lattices after mapload when one of them just gets deleted anyway. Stops unhelpful stack_trace messages from blocking CI from passing. ## Changelog Not player facing. |
||
|
Y0SH1M4S73R
|
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> |
||
|
SmArtKar
|
6a36707770 |
Iron material tiles can now be used to tile lattice to make plating (same for other similar interactions) (#88674)
## About The Pull Request Added a helper to check if something is a tile made out of iron, and changed all plating placement code to use it. ## Why It's Good For The Game Its very easy to misclick or get confused and make the wrong type of tile in the crafting menu, and since material tiles made from iron aren't a subtype of ***iron*** tiles, you won't be able to use them to make plating. Space already accounts for this, but lattice, chasms, openspace and foam plating do not. ## Changelog 🆑 qol: Iron material tiles can now be used to tile lattice to make plating /🆑 |
||
|
grungussuss
|
a89620dfc7 |
Fixes items not falling from a lattice's loc after it's deconstructed (#88439)
## About The Pull Request closes https://github.com/tgstation/tgstation/issues/81060 ## Changelog 🆑 grungussuss fix: fixed items not falling from a lattice after being deconstructed/destroyed /🆑 |
||
|
larentoun
|
692540a7b9 |
Singularity_pull() standartize (#87304)
## About The Pull Request Previous attempt - https://github.com/tgstation/tgstation/pull/87227 `/atom/proc/singularity_pull(obj/singularity/singularity, current_size)` has first arg typed, but other procs were just referencing it as a un-typed variable. Since args are not standartized AND `atom/proc/singularity_pull(obj/singularity/singularity, current_size)` is out-dated, since it can be called by things that has `/datum/component/singularity` - not just by `obj/singularity/singularity` - This PR just adds args to every `proc/singularity_pull()` as follows: `proc/singularity_pull(atom/singularity, current_size)` ## Why It's Good For The Game Standartization ## Changelog No changelog needed |
||
|
grungussuss
|
58501dce77 |
Reorganizes the sound folder (#86726)
## About The Pull Request <details> - renamed ai folder to announcer -- announcer -- - moved vox_fem to announcer - moved approachingTG to announcer - separated the ambience folder into ambience and instrumental -- ambience -- - created holy folder moved all related sounds there - created engineering folder and moved all related sounds there - created security folder and moved ambidet there - created general folder and moved ambigen there - created icemoon folder and moved all icebox-related ambience there - created medical folder and moved all medbay-related ambi there - created ruin folder and moves all ruins ambi there - created beach folder and moved seag and shore there - created lavaland folder and moved related ambi there - created aurora_caelus folder and placed its ambi there - created misc folder and moved the rest of the files that don't have a specific category into it -- instrumental -- - moved traitor folder here - created lobby_music folder and placed our songs there (title0 not used anywhere? - server-side modification?) -- items -- - moved secdeath to hailer - moved surgery to handling -- effects -- - moved chemistry into effects - moved hallucinations into effects - moved health into effects - moved magic into effects -- vehicles -- - moved mecha into vehicles created mobs folder -- mobs -- - moved creatures folder into mobs - moved voice into mobs renamed creatures to non-humanoids renamed voice to humanoids -- non-humanoids-- created cyborg folder created hiss folder moved harmalarm.ogg to cyborg -- humanoids -- -- misc -- moved ghostwhisper to misc moved insane_low_laugh to misc I give up trying to document this. </details> - [X] ambience - [x] announcer - [x] effects - [X] instrumental - [x] items - [x] machines - [x] misc - [X] mobs - [X] runtime - [X] vehicles - [ ] attributions ## Why It's Good For The Game This folder is so disorganized that it's vomit inducing, will make it easier to find and add new sounds, providng a minor structure to the sound folder. ## Changelog 🆑 grungussuss refactor: the sound folder in the source code has been reorganized, please report any oddities with sounds playing or not playing server: lobby music has been repathed to sound/music/lobby_music /🆑 |
||
|
tgstation-ci[bot]
|
9a9b428b61 |
Wallening Revert [MDB Ignore][IDB Ignore] (#86161)
This PR is reverting the wallening by reverting everything up to
|
||
|
YesterdaysPromise
|
fec946e9c0 |
/Icon/ Folder cleansing crusade part, I think 4; post-wallening clean-up. (#85823)
Hello everybuddy, your number three rated coder-failure here to clean up some mess. This PR accomplishes some of the more major structural clean up changes I wanted to do with /obj/ folder, but decided to wait on until wallening gets merged, and so, time has come. Several things to still be done, although I know these cleaning PR's are quite a load, so will wait for this one to get done with first. ## Why It's Good For The Game Saner spriters, better sprites, less annoyance. Also deleted a whole load of redundancy this time around, a lot of sprites which existed simultaniously in two places now got exit their quantum superposition. |
||
|
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> |
||
|
MrMelbert
|
3d20e557f4 |
All lattices make catwalk footsteps (instead of just catwalks) (#84917)
## About The Pull Request Lattices make catwalk sounds when walked across, much like their children catwalks do ## Why It's Good For The Game If you've ever walked across the tramway, it's really jarring to go from catwalk (footstep sound) -> lattice (no footstep sound) -> catwalk (footstep sound) -> lattice (no footstep sound) But they'd probably sound the same in practice ## Changelog 🆑 Melbert qol: Lattices now make the same footstep sound as catwalks /🆑 |
||
|
MGOOOOOO
|
66acc9007b |
Fixes catwalk deconstruction not yielding iron rods (#83909)
## About The Pull Request Fixes #83875. ## Why It's Good For The Game I was able to reproduce this bug in master, catwalk deconstruction should definitely return the materials used. |
||
|
SyncIt21
|
6dc40ca522 |
Standardizes object deconstruction throughout the codebase. (#82280)
## About The Pull Request When it comes to deconstructing an object we have `proc/deconstruct()` & `NO_DECONSTRUCT` Lets talk about the flag first. **Problems with `NO_DECONSTRUCTION`** I know what the comment says on what it should do https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/code/__DEFINES/obj_flags.dm#L18 But everywhere people have decided to give their own meaning/definition to this flag. Here are some examples on how this flag is used **1. Make the object just disappear(not drop anything) when deconstructed** This is by far the largest use case everywhere. If an object is deconstructed(either via tools or smashed apart) then if it has this flag it should not drop any of its contents but just disappear. You have seen this code pattern used everywhere https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/code/game/machinery/constructable_frame.dm#L26-L31 This behaviour is then leveraged by 2 important components. When an object is frozen, if it is deconstructed it should just disappear without leaving any traces behind https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/code/datums/elements/frozen.dm#L66-L67 By hologram objects. Obviously if you destroy an hologram nothing real should drop out https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/code/modules/holodeck/computer.dm#L301-L304 And there are other use cases as well but we won't go into them as they aren't as significant as these. **2. To stop an object from being wrenched ??** Yeah this one is weird. Like why? I understand in some instances (chair, table, rack etc) a wrench can be used to deconstruct a object so using the flag there to stop it from happening makes sense but why can't we even anchor an object just because of this flag? https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/code/game/objects/objs.dm#L368-L369 This is one of those instances where somebody just decided this behaviour for their own convenience just like the above example with no explanation as to why **3. To stop using tools to deconstruct the object** This was the original intent of the flag but it is enforced in few places far & between. One example is when deconstructing the a machine via crowbar. https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/code/game/machinery/_machinery.dm#L811 But machines are a special dual use case for this flag. Because if you look at its deconstruct proc the flag also prevents the machine from spawning a frame. https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/code/game/machinery/_machinery.dm#L820-L822 How can 1 flag serve 2 purposes within the same type? **4. Simply forget to check for this flag altogether** Yup if you find this flag not doing its job for some objects don't be surprised. People & sometimes even maintainers just forget that it even exists https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/code/game/objects/items/piggy_bank.dm#L66-L67 **Solution** These are the main examples i found. As you can see the same flag can perform 2 different functions within the same type and do something else in a different object & in some instances don't even work cause people just forget, etc. In order to bring consistency to this flag we need to move it to the atom level where it means the same thing everywhere. Where in the atom you may ask? .Well, I'll just post what MrMelbert said in https://github.com/tgstation/tgstation/pull/81656#discussion_r1503086862 > ...Ideally the .deconstruct call would handle NO_DECONSTRUCTION handling as it wants, Yup that's the ideal case now. This flag is checked directly in `deconstruct()`. Now like i said we want to give a universal definition to this flag and as you have seen from my examples it is used in 3 cases 1) Make an object disappear(doesn't dropping anything) when deconstructed 2) Stop it from being wrenched 3) Stop it from being deconstructed via tools We can't enforce points 2 & 3 inside `deconstruct()` which leaves us with only case 1) i.e. make the object disappear. And that's what i have done. Therefore after more than a decade or since this flag got introduced `NO_DECONSTRUCT` now has a new definition as of 2024 _"Make an object disappear(don't dropping anything) when deconstructed either via tools or forcefully smashed apart"_ Now i very well understand this will open up bugs in places where cases 2 & 3 are required but its worth it. In fact they could even be qol changes for all we know so who knows it might even benefit us but for now we need to give a universal definition to this flag to bring some consistency & that's what this PR does. **Problem with deconstruct()** This proc actually sends out a signal which is currently used by the material container but could be used by other objects later on. https://github.com/tgstation/tgstation/blob/3e84c3e6dad33c831ac259f52f2f023680e4899b/code/game/objects/obj_defense.dm#L160 So objects that override this proc should call its parent. Sadly that isn't the case in many instances like such https://github.com/tgstation/tgstation/blob/3e84c3e6dad33c831ac259f52f2f023680e4899b/code/game/machinery/deployable.dm#L20-L23 Instead of `return ..()` which would delete the object & send the signal it deletes the object directly thus the signal never gets sent. **Solution** Make this proc non overridable. For objects to add their own custom deconstruction behaviour a new proc has been introduced `atom_deconstruct()` Subtypes should now override this proc to handle object deconstruction. If objects have certain important stuff inside them (like mobs in machines for example) they want to drop by handling `NO_DECONSTRUCT` flag in a more carefully customized way they can do this by overriding `handle_deconstruct()` which by default delegates to `atom_deconstruct()` if the `NO_DECONSTRUCT` flag is absent. This proc will allow you to handle the flag in a more customized way if you ever need to. ## Why It's Good For The Game 1) I'm goanna post the full comment from MrMelbert https://github.com/tgstation/tgstation/pull/81656#discussion_r1503086862 > ...Ideally the .deconstruct call would handle NO_DECONSTRUCTION handling as it wants, but there's a shocking lack of consistency around NO_DECONSTRUCTION, where some objects treat it as "allow deconstruction, but make it drop no parts" and others simply "disallow deconstruction at all" This PR now makes `NO_DECONSTRUCTION` handled by `deconstruct()` & gives this flag the consistency it deserves. Not to mention as shown in case 4 there are objects that simply forgot to check for this flag. Now it applies for those missing instances as well. 2) No more copying pasting the most overused code pattern in this code base history `if(obj_flags & NO_DECONSTRUCTION)`. Just makes code cleaner everywhere 3) All objects now send the `COMSIG_OBJ_DECONSTRUCT` signal on object deconstruction which is now available for use should you need it ## Changelog 🆑 refactor: refactors how objects are deconstructed in relation to the `NO_DECONSTRUCTION` flag. Certain objects & machinery may display different tool interactions & behaviours when destroyed/deconstructed. Report these changes if you feel like they are bugs /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
Paxilmaniac
|
acb374fc77 |
Makes placing plating on lava-proof rods delete the rods and not break lighting on that tile for the rest of the round (#80876)
## About The Pull Request See title ## Why It's Good For The Game 1. Its a bit odd that the rods are still there and on top of the new tile you placed, considering you were build on top of them. 2. Because building didn't use place on top, the lighting on the tile would be broken and made entirely black for the rest of the round. Slightly annoying when you're constructing something on top of it! ## Changelog 🆑 qol: The heat-proof catwalk made by heat-proof rods will go away when a tile is placed on it, rather than sticking around and needing to be removed manually fix: The lighting will not irreparably break on tiles where plating was placed on lava-proof catwalks code: Some single letter variables and the structure of the code around placing tiles on lava-proof catwalks has been improved /🆑 |
||
|
san7890
|
5ce9d5806d |
Scopes NODECONSTRUCT_1 from flags_1 to obj_flags (#80104)
This flag only worked on the `/obj/structure` and `/obj/machinery` level, so let's rescope it from `flags_1` and put it where it belongs - `obj_flags`. Bitflag operators should be scoped to their subtype specific bitfield, not really useful to have this take up a spot on the `/atom` level if absolutely nothing other than `/obj`s use it. |
||
|
Jeremiah
|
7a1b1fa9ad |
Splits placeontop proc (#79702)
## About The Pull Request I find the proc hard to read honestly. There's no reason we can't split this into two functions - the secondary functionality is used only once, in reader.dmm. ## Why It's Good For The Game Code improvement Glorious snake case ## Changelog N/A nothing player facing --------- Co-authored-by: san7890 <34697715+san7890@users.noreply.github.com> |
||
|
SyncIt21
|
66f726dfe3 |
General code maintenance for rcd devices and their DEFINE file (#78443)
## About The Pull Request The changes made can be best summarized into points **1. Cleans up `code/_DEFINES/construction.dm`** Looking at the top comment of this file https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/__DEFINES/construction.dm#L1 One would expect stuff related to materials, rcd, and other construction related stuff. Well this file is anything but Why is there stuff related to food & crafting over here then? https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/__DEFINES/construction.dm#L91-L94 It gets worse why are global lists declared here? https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/__DEFINES/construction.dm#L115 There is a dedicated folder to store global lists i.e. `code/_globalvars/lists` for lists like these. These clearly don't belong here On top of that a lot of construction related defines has been just dumped here making it too large for it's purposes. which is why this file has been scraped and it's 1. crafting related stuff have been moved to its `code/_DEFINES/crafting.dm` 2. global lists for crafting moved to `code/_globalvars/lists/crafting.dm` 3. Finally remaining construction related defines split apart into 4 file types under the new `code/_DEFINES/construction` folder - `code/_DEFINES/construction/actions.dm` -> for wrench act or other construction related actions - `code/_DEFINES/construction/material.dm` -> contains your sheet defines and cable & stack related values. Also merged `code/_DEFINES/material.dm` with this file so it belongs in one place - `code/_DEFINES/construction/rcd.dm` -> dedicated file for everything rcd related - `code/_DEFINES/construction/structures.dm` -> contains the construction states for various stuff like walls, girders, floodlight etc By splitting this file into multiple meaningful define file names will help in reducing merge conflicts and will aid in faster navigation so this is the 1st part of this PR **2. Debloats the `RCD.dm` file(Part 1)** This uses the same concepts as above. i.e. moving defines into their appropriate files for e.g. https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/game/objects/items/rcd/RCD.dm#L170 1. Global vars belong in the `code/_globalvars` folder so these vars and their related functions to initialize them are moved into the `code/_globalvars/rcd.dm` file 2. See this proc https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/game/objects/items/rcd/RCD.dm#L200 This proc does not belong to the `obj/item/construction/rcd` type it's a global "helper function" this is an effect proc as it creates rcd holograms so it has been moved to the `code/game/objects/effects/rcd.dm` file which is a global effect that can be used by anyone And with that we have moved these vars & procs into their correct places & reduced the size of this file . We can go even further **3. Debloats the `RCD.dm` file(Part 2)** This deals with the large list which contains all the designs supported by the RCD https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/game/objects/items/rcd/RCD.dm#L42 This list contains a lot of local defines. We can scrape some of them and reduce the overall bulkiness & memory requirements of this list and so the following defines ``` #define WINDOW_TYPE "window_type" #define COMPUTER_DIR "computer_dir" #define WALLFRAME_TYPE "wallframe_type" #define FURNISH_TYPE "furnish_type" #define AIRLOCK_TYPE "airlock_type" #define TITLE "title" #define ICON "icon" #define CATEGORY_ICON_STATE "category_icon_state" #define CATEGORY_ICON_SUFFIX "category_icon_suffix" #define TITLE_ICON "ICON=TITLE" ``` Have all been removed making this list a lot more cleaner. Why? because a lot of these are just semantic sugar, we can infer the value of a lot of these defines if we just know the type path of the structure the rcd is trying to build for e.g. take these 2 defines https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/game/objects/items/rcd/RCD.dm#L13-L15 These defines tell the rcd UI the name and the icon it should display. Rather than specifying these manually in the design we can infer them like this ``` var/obj/design = /obj/structure/window //let's say the rcd is trying to build an window var/name = initial(design.name) //we have inferred the name of the design without requiring TITLE define var/icon = initial(design.icon_state) //we have inferred the icon of the design without requiring ICON define ``` And so by using similar logic to the remaining defines we can eliminate a lot of these local defines and reduce the overall size of this list. The same logic applies to the different modes of construction, the following defines https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/__DEFINES/construction.dm#L186-L192 Have all been removed and replaced with a single value `RCD_STRUCTURE` All these modes follow the same principle when building them 1. First check the turf if the structure exists. If it does early return 2. If not create a new structure there and that's it So rather than creating a new construction mode every time you want to add a new design we can use this mode to apply this general approach every time The design list has also now been made into a global list rather than a private static list. The big advantage to this is that the rcd asset cache can now access this list and load the correct icons from the list directly. This means you no longer have to manually specify what icons you want to load which is the case currently. https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/modules/asset_cache/assets/rcd.dm#L8-L9 This has lead to the UI icons breaking twice now in the past - #74194 - #77217 Hopefully this should never repeat itself again **4. Other RCD like device changes** - Fixed the broken silo link icon when the radial menu of the RLD was opened - replaced a lot of vars inside RLD with defines to save memory - Small changes to `ui_act` across RCD, Plumbing RCD and RTD - Removed unused vars in RCD and snowflaked code - Moved a large majority of `ui_data()` to `ui_static_data()` making the experience much faster Just some general clean up going on here **5. The Large majority of other code changes** These are actually small code changes spread across multiple files. These effect the `rcd_act()` & the `rcd_vals()` procs across all items. Basically it - Removes a large majority of `to_chat()` & `visible_message()` calls. This was done because we already have enough visual feedback of what's going on. When we construct a wall we don't need a `to_chat()` to tell us you have a built a wall, we can clearly see that - replaces the static string `"mode"` with a predefined constant `RCD_DESIGN_MODE` to bring some standard to use across all cases Should reduce chat spam and improve readability of code. **6. Airlock & Window names** The rcd asset cache relies on the design name to be unique. So i filled in the missing names for some airlocks & windows which are subjective and open to change but must have some value **7 Removes Microwave PDA upgrade** The RCD should not be allowed to build this microwave considering how quickly it can spawn multiple structures and more importantly as it's a special multipurpose machine so you should spend some effort in printing it's parts and acquiring tools to complete it. This upgrade makes obsolete the need to carry an - A RPED to install the parts - A screwdriver to complete the frame - The circuit board for the microwave The most important point to note here is that whenever an RPED/circuit board is printed at an lathe it charges you "Lathe Tax". The RCD with this upgrade would essentially bypass the need to "Pay Taxes" at these lathes as you are just creating a circuit board from thin air. This causes economy imbalance(10 cr per print) which scales up the more of these machines you make so to avoid this let's end the problem here Not to mention people would not find the need to print the circuit board for a regular microwave now if they have an RCD because they can just make this microwave type making the need for a regular microwave completely pointless. Just build a machine frame with the RCD and complete the microwave from there ## Changelog 🆑 code: moved global vars, lists and helper procs for construction related stuff to their appropriate files code: reduced overall code size & memory of rcd design list and removed unused defines refactor: removed a ton of chat alerts for rcd related actions to help reduce chat spam refactor: some airlock & window default names have changed fix: broken icon in radial menu of rld silo link remove: removes microwave pda upgrade from RCD. It's a special machine so spend some time in building it rather than shitting them out for free with the RCD. Use the RCD upgrade to spawn a machine frame instead & go from there /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
iwishforducks
|
7c9cf40ad4 |
Fixes RCD'ing lattices in open space (#77895)
## About The Pull Request If you RCD a lattice with floor/wall mode on icebox, it won't actually place down the floor because the open space is not "space" - this switches the check to openspace, allowing you to fix floors on icebox by clicking on lattices. For some reason this would also cause you to waste your matter units on this action. ## Why It's Good For The Game fix good ## Changelog 🆑 fix: You should be able to click on lattices on icebox with the RCD and construct a floor now /🆑 |
||
|
iwishforducks
|
74a9b317aa |
Fixes cost values of RCDs (#77650)
## About The Pull Request fixes cost values to be 1:1 of what the construction would have costed in manual construction for the RCD. also changes all decaseconds to seconds in code for clarity. the biggest change is windows, they used to cost more than they needed for manual construction: grille - 4mu - 1 iron sheet - 100% efficiency directional normal window - 6mu - 1 glass sheet - 66% efficiency directional reinforced window - 9mu - 1 reinforced glass sheet - 66% efficiency fulltile normal window - 12mu - 2 glass sheets - 66% efficiency fulltile reinforced window - 15mu - 2 reinforced glass sheets - 80% efficiency this PR fixes all of these to be 100% efficient by lowering their matter costs, among some other items like racks or reflector frames. ## Why It's Good For The Game consistency for material costs is good. most of these incorrect material values are also for things that don't matter, like racks or reflector frames. also decaseconds are gross looking in code ## Changelog 🆑 fix: Some RCD constructs took more material than manual construction. The RCD cost should be consistent in comparison to manual construction now. /🆑 |
||
|
Time-Green
|
203aecbf63 |
[no gbp] Fixes runtimes in shuttle event and shuttle cling (#77343)
Fixes no-candidate runtime from pick() on an empty list Fixes spawning null movables if run out of mobs to spawn Fixes shuttle cling qdeling on Initialize due to lattices not counting as hyperspace 🆑 runtime: Fixes runtimes in shuttle event and shuttle cling code /🆑 --------- Co-authored-by: Jacquerel <hnevard@gmail.com> |
||
|
Ghom
|
c1122a0ae9 |
Adds an element to water turfs that makes things... look like they're actually immersed in water. (#76208)
## About The Pull Request This PR adds an element, for now added to water turfs, that gives passing movables an overlay to make them look immersed in that turf. You can definitely see in the code what sort of stupid stuff I've had to do to work around some of the flaws with the inbuilt features. Why? Because I needed a (vis_contents) overlay that: - can cover the entire width of the movable it's added to, whether it has a 32 px icon, 64, 96 etc, plus some to be safe. - doesn't look misplaced around movables with an icon larger than 32 px. - can be animated, so it doesn't rotate or scale (or rather, do so but in the opposite direction) with living mobs when resized, spinning or lying down or standing up, despite the KEEP_TOGETHER appearance flag, which ignores whether the overlay has the RESET_TRANSFORM flag. - looks inset in the movable and doesn't spill into other movables of the same plane (that's what happened with normal inset overlays without the KEEP_TOGETHER flag) - doesn't render above other movables covering the owner of the overlay. If someone comes with a better and tested solution, go and tell I guess. How visuals are handled by this engine still eludes me at times, but I doubt planes would be a better solution to this. The rest of the PR includes checks to make sure the overlay isn't added to movables with planes lower/higher than FLOOR_PLANE/ABOVE_ALL_MOB_PLANE, that are flying or being thrown, as well as certain types such as effects. ## Why It's Good For The Game Adding some literal immersion to the game, since movables and mobs look like they're treading on water like Jesus right now. You can see a couple screenshots by scrolling down a little. ## Changelog 🆑 image: walking on water will now immerse you in it... visually, at least. /🆑 |
||
|
Ghom
|
d4cdd6b63e |
Replaces lava and chasm's "safeties" and ignoring turf slowdown on catwalks with traits and a new element. (#76376)
## About The Pull Request This adds a new element for movables that grants turfs they're in traits, changes lava and the chasm component to check for traits instead, ditto for turf slowdown. It also implements another trait that prevents wet floor from slipping people, as well as some other changes (feel free to opine on them really): - Tables and conveyor belts now stop turf slowdown, much like catwalks, as I imagine people walking on them are not really touching the floor. (I'd include protection against lava too... until they melt, but that'd mean finding a way to have these objects burn in the first place, and lava code is still stupid despite a years old refactor I did) - Tables also stop slippery turfs from slipping (bananas, soaps etc. still apply). I wish there were a way to make some objects slippery by coating them in water vapor or splashing water/lube, but that's outside the scope of this PR. - Fixed an edge case in which a mob standing on a lava turf would be left permanently visually on fire if the lava is changed to another kind of turf. - Removed unused code from stone tiles. I'm going to include these traits in that global list for admin-added traits... tomorrow perhaps. 💤 ## Why It's Good For The Game Replacing some hard-coded mechanics with easier to use traits and an element, which I also need for the submerge element PR. ## Changelog 🆑 refactor: Replaced hardcoded "safeties" for lava, chasms and ignoring turf slowdowns on catwalks with traits. balance: much like catwalks, tables and conveyors also disable turf slowdowns. balance: slippery turfs won't slip you when walking on a table. fix: Fixed an edge case in which a mob standing on a lava turf would be left visually but permanently on fire if the lava is changed to another kind of turf. /🆑 |
||
|
Ghom
|
55e00665f3 |
Walking on conveyors, catwalks and tables no longer plays the footstep sound of the turf, and have theirs. (#76391)
## About The Pull Request Adds a footstep_override element to the game, that allows object to do what it reads on the tin. Only conveyor belts, catwalks and tables use it for now. ## Why It's Good For The Game Consistency. If you're walking on a table or catwalk, the sound of shoes trudging on snow or lava shouldn't be played. Tested. ## Changelog 🆑 sound: Walking on conveyors, catwalks and tables no longer plays the footstep sound of the turf. They have theirs. /🆑 |
||
|
Time-Green
|
8788e48378 |
Shuttle events (#76008)
## About The Pull Request https://github.com/tgstation/tgstation/assets/7501474/a2d83ce8-eba1-42d9-a1f8-9d73f7c40b21 Adds shuttle events! Stuff can now start to happen outside the shuttle, either benign or spicy (but usually just fun to watch)! ## Why It's Good For The Game The shuttle escape sequence is an important part of the game, uniting about every player surviving player. Recently, #71906 has made the escape sequence more forgiving as well as more interesting by conditionally doubling the playing field. The area outside the shuttle is still mostly empty though, except for the few people being spaced, daredevils and the occasional epic space fight. This PR adds adds some space events to spice up the outside of the shuttle! This both gives people something too look at, making the escape sequence feel less static and more lively, as well as give people a reason to go outside and get the full experience of ~being decapitated by a meteor~ swimming with the fishes! <details> <summary>Shuttle Events</summary> **Friendly carp swarm** Spawns a group of carp that flies past the shuttle, completely friendly unless provoked. **Friendly meteors** Spawns a lot of strong meteors, but they all miss the shuttle. Completely safe as long as you don't go EVA **Maintenance debris** Picks random stuff from the maintenance spawn pool and throws it at the shuttle. Completely benign, unless you get hit in the head by a toolbox. Could get you some cool stuff though! **Dust storm** Spawns a bunch of dust meteors. Has a rare chance to hit the shuttle, doing minimal damage but can damage windows and might need inflight maintenance **Alien queen** One in every 250 escapes. Spawns a player controlled alien queen and a ripley mech. RIP AND TEAR!! Really not that dangerous when you realize the entire crew is on the shuttle and the queen is fat as fuck, but can still be fun to throw people around a bit before being torn to shreds. **ANGRY CARP** Once in every 500 escapes. Spawns 12 normal carp and 3 big carps, who may just decide to go through the shuttle or try and bust through the window if you look at them wrong. Somewhat dangerous, you could stay away from the windows and try to hide, or more likely shoot at them and weld the windows **Fake TTV** Lol **Italian Storm** Once in every 2000 rounds. Throws pasta, pizza and meatballs at the shuttle. Definitely not me going off the rails with a testing event **Player controlled carp trio** Once in every 100 escapes. Spawns three player controlled carp to harass the shuttle. May rarely be a magicarp, megacarp or chaos carp. I can't honestly see them do anything other than be annoying for 3 seconds and die There are some other admin only ones: a group of passive carps going directly through the shuttle and just being little shits, and a magic carp swarm </details> Events are selected seperately, there isn't a crazy weighting system, each just has a chance to run, and multiple could run at once. They also don't immediately trigger, so people can get settled a bit, and to make sure just waiting out the more dangerous ones is still a valid strategy. ## Changelog 🆑 add: Adds shuttle events! If shuttle escapes weren't exciting before (doubtful), they definitely are now! I'm joking it's mostly an atmosphere thing. admin: Adds an admin panel to interact with shuttle events, under the Events tab: Change Shuttle Events fix: Objects spawned in hyperspace will properly catch hyperspace drift /🆑 There's a few things I'd like to do later (another PR) (honestly anyone can do them because I suck at follow-ups), because this is too big as is: - Hijack triggered shuttle events - More events (got a lot of cool suggestions, but I'm putting most of them on hold) - Maybe stration announcements if some more dangerous ones get added - Structures appearing next to the escape shuttle??? --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
|
SyncIt21
|
3c908fc280 |
Some more RCD Designs & Patches (#72757)
## About The Pull Request Adds some more stuff you can build with the RCD 1. Under structures you can now build/deconstruct catwalks & construct Reflector Frames. Destorying a catwalk will cut any cable on it leaving pieces of it behind  2. If you have the frames upgrade you can construct APC, Air Alarm & Fire Alarm frames on walls & Flood light fixtures[fully wired]. It only creates the wall mount and sticks it on the wall. Wiring, Circuits and finishing the frame is still your job  3. If you have the furnishing upgrade you can create racks & beds & additional bar stool  **Important Code Refractors** 1. `/turf/closed/wall/proc/try_wallmount()` will return true only after you have successfully mounted the wallframe or stuck an poster on it & not simply check if you are trying to mount a valid thing on it 2. `apc_tool_act/rcd_act()` was incorrectly checking passed_mode for the simple circuit upgrade and not the `the_rcd.upgrade `flag. Thats fixed now to 3. newly created APC's weren't assigning themselves to their areas allowing multiple to be created in one area. Thats fixed now 4. Walls, Airlocks & other stuff could be built on tiles having something dense that would block it. For example a wall could be build on top of a machine frame!!. Thats also fixed now ## Why It's Good For The Game More stuff you can build rapidly with the RCD ## Changelog 🆑 add: more designs for the rcd refactor:` try_wallmount()` to return true only after successful mount fix: `apc_tool_act/rcd_act()` incorrecly checking for simple circuits upgrade in the wrong variable fix: newly created APC's not assigning themselves to their areas. fix: rcd building structures [walls, airlocks etc] on turf's that already have structures on them /🆑 |
||
|
Zephyr
|
6a0c884410 |
[no gbp] removes all duplicate armor datums (#72354)
## About The Pull Request closes #72348 Title ## Why It's Good For The Game My bad ## Changelog Heres the script I used this time if you want to ```cs var baseDir = Environment.CurrentDirectory; var allFiles = Directory.EnumerateFiles($@"{baseDir}\code", "*.dm", SearchOption.AllDirectories).ToList(); var known = new Dictionary<string, List<KeyValuePair<string, int>>>(); foreach (var file in allFiles) { var fileLines = File.ReadAllLines(file); for (var i = 0; i < fileLines.Length; i++) { var line = fileLines[i]; if (line.StartsWith("/datum/armor/")) { var armorName = line.Replace("/datum/armor/", "").Trim(); if (!known.ContainsKey(armorName)) known[armorName] = new List<KeyValuePair<string, int>>(); var knownList = known[armorName]; knownList.Add(new KeyValuePair<string, int>(file, i)); } } } Console.WriteLine($"There are {known.Sum(d => d.Value.Count)} duplicate armor datums."); var duplicates = new Dictionary<string, List<int>>(); foreach (var (_, entries) in known) { var actuals = entries.Skip(1).ToList(); foreach (var actual in actuals) { if (!duplicates.ContainsKey(actual.Key)) duplicates[actual.Key] = new List<int>(); duplicates[actual.Key].Add(actual.Value); } } Console.WriteLine($"There are {duplicates.Count} files to update."); foreach (var (file, idxes) in duplicates) { var fileContents = File.ReadAllLines(file).ToList(); foreach (var idx in idxes.OrderByDescending(i => i)) { string line; do { line = fileContents[idx]; fileContents.RemoveAt(idx); } while (!String.IsNullOrWhiteSpace(line)); } File.WriteAllLines(file, fileContents); } ``` |
||
|
Zephyr
|
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> |
||
|
Mothblocks
|
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. |
||
|
Mothblocks
|
943c04bae5 |
Save 2.2s minimum (with zero ruins, likely a good bit more in production) of atom init time (#69564)
Pre-sort smoothing_groups and canSmoothWith Without any ruins, these sorts were taking more than 0.6s, and the bulk of the runtime cost of sortTim during init time. This only happens on init and they are never changed apart from that, so pre-sorts everything and adds a unit test (in the form of #ifdef UNIT_TESTS, because you can't initial a list) to ensure that they are proper. Keep visibilityChanged() to mapload only for turf/Initialize Saves about 0.4s worst case scenario (e.g. with no ruins). Very expensive code (175k loop iterations) for 0 side effects. Space areas now have the fullbright overlay, not the space turfs Saves about 0.8s worst case scenario. Seems to work fine with starlight. Remove is_station_level check for window spawners assigning RCD memory. Saves about 0.3s worst case scenario. The logic for this isn't consistent since neither walls nor floors check this (for performance), plus some minor micro-opts to spawners. Optimize is_station_level Doubles in speed, used heavily in /turf/open/floor and in other initialization procs. Bit hard to tell exactly how much is saved, though. |
||
|
Thunder12345
|
86eddc3554 |
Mining Outpost Overhaul: Island Living Edition (#67796)
Replaced the old mining outpost with a new base consisting of separate buildings on islands in the middle of lava. Added a few new areas and decorations to fill out the outpost. Changed the underfloor accessibility of lava so cables and pipes don't mysteriously disappear as they cross catwalks over lava. The current mining station is fairly boring and dated. In addition, the general layout of the outpost was bland and uninspired, about as exciting as any other hallway. This replacement offers a new and unique take with an interesting layout and new dangers to be aware of. The bridges between buildings are exposed to the weather, meaning you could find yourself forced to choose between waiting out a storm in an isolated building with a potentially unfriendly roommate, or running through the storm to get back to a shuttle. Power and communications are also more vulnerable in the new base, placed in a building on the mainland where ne'er-do-wells could gain access unnoticed and sabotage them, making the mining outpost less of a safe space with little risk of anything going seriously wrong. You don't get access to these just for having mining access, better call the relevant portion of engineering to help you. Gulag prisoners also get a few new options to keep security on their toes, with a few different options for escape routes that encourage the warden to keep an eye on their charges instead of ignoring the gulag while waiting for the prisoners to do their sentences or kill themselves. |
||
|
Mothblocks
|
0f3c4e51f7 |
Modernizing Radiation -- TL;DR: Radiation is now a status effect healed by tox healing, and contamination is removed (#62265)
Implements the Modernizing radiation design document ( https://hackmd.io/@tgstation/rJNIyeBHt ) and replaces the current radiation sources with the new system, as well as replacing/removing a bunch of old consumers of radiation that either had no reason to exist, or could be replaced by something else. Diverges from the doc in that items radiation don't go up like explained. I was going to, but items get irradiated so easily that it just feels pretty lame. Items still get irradiated, but it's mostly just so that radiation sources look cooler (wow, lots of stuff around going green), and for things like the geiger counter. Instead of the complicated radiation_wave system, radiation now just checks everything between the radiation source and the potential target, losing power along the way based on the radiation insulation of whats in between. If this reaches too low a point (specified by radiation_pulse consumers), then the radiation will not pass. Otherwise, will roll a chance to irradiate. Uranium structures allow a delay before irradiating, so stay away! |
||
|
Watermelon914
|
375a20e49b |
Refactors most spans into span procs (#59645)
Converts most spans into span procs. Mostly used regex for this and sorted out any compile time errors afterwards so there could be some bugs. Was initially going to do defines, but ninja said to make it into a proc, and if there's any overhead, they can easily be changed to defines. Makes it easier to control the formatting and prevents typos when creating spans as it'll runtime if you misspell instead of silently failing. Reduces the code you need to write when writing spans, as you don't need to close the span as that's automatically handled by the proc. (Note from Lemon: This should be converted to defines once we update the minimum version to 514. Didn't do it now because byond pain and such) |
||
|
Fikou
|
f6dfc68360 |
repaths plasteel tiles to iron (#56644)
Repaths plasteel tiles and turfs to iron. We're in too deep to back out now |
||
|
LemonInTheDark
|
1ff673db0d | Fixes catwalks smoothing with lattices (#54829) | ||
|
L
|
fb38066f09 | bitmask | ||
|
L
|
5a21a0d92f | objs | ||
|
TemporalOroboros
|
6e950daccc | Defines damage flags. (#53158) | ||
|
Critawakets
|
4d6c51c5e1 | Fixes lattice and operating table smoothing. | ||
|
Rohesie
|
b0726e032b |
Icon smooth refactor (#52864)
bitflag list construct added: an associative list of bitflags for cheap and quick element comparison between two lists using the same system.
canSmoothWith list turned into a bitflag list.
smoothing_groups list added to substitute the type path list.
smoothing procs turned into atom procs, refactored and optimized a bit.
smooth directions redefined in order to fit in 8 bits for a future smoothing system
some variable names changed, foreseeing a second smoothing system
SMOOTH_OBJ flag added, for things that need to scan turfs for smoothing. The old locate() optimization has the risk of returning false negatives by finding a child and returning null while there might be one of the wanted type as well, as it doesn't match the type exactly.
SMOOTH_TRUE and SMOOTH_MORE condensed into SMOOTH_CORNERS. The old behavior can be replicated using smoothing groups without loss.
Does very minor code cleanup.
Processing-wise didn't find a noticeable difference. The system loses on init a bit by setting the bitflag_lists, and by scanning whole turf contents for object smoothing (increasing accuracy), and gains by making less checks per target to smooth, through the same bitflag_lists.
Memory-wise there should be a small improvement, given that on the old system we had 63512 canSmoothWith lists (a few typelists, most unique), and on this new system canSmoothWith + smoothing_groups are both bitflag_lists from the same pool, totaling 46 in number.
Could be tested a bit to see if I missed any icons not properly smoothing.
|
||
|
Rohesie
|
cb9f81e43c |
Renames smooth var to smoothing_flags (#52427)
* smooth_flags * SMOOTH_FALSE * smooth_flags |
