mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-12 00:27:31 +01:00
observer_fix_tm
148 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 san7890
|
e0827de4b5 |
[MDB Ignore] Unrestricted Airlocks - Door Delays (#94040)
## About The Pull Request This PR adds a change to a pretty prevalent feature that's been around since #66588 (April 28th, 2022). Although it has been controversial to some extent, I believe that it was a good change in principle for reasons I will later get into. For now, this is what the PR does: * All _station_ unrestricted door helpers (e.g. those in maintenance) have been replaced with a subtype that adds a random 2-3 second delay to opening the door, using a new "unrestricted latch" feature. **This does not occur if the user has regular access to that door.** * The unrestricted side will initiate a do_after and plays a distinct small hissing sound (because I presume you're disengaging some hydraulic lever on that side), after which the door will open as players have come to expect. * While you're engaging the lever, you will be resistant to pressure movements as you are presumably holding onto the lever or something. All other movements (e.g. voluntary, being shoved, etc.) will continue to function as expected. * We will statistically tabulate each time someone attempts to use the unrestricted "lever", and every time one successfully occurs. This is just for analysis to see player trends as we have lacked this over the last 3.5 years. Here's a link to the sound I added: https://freesound.org/people/Usernameis1337/sounds/632755, the version in this PR was converted using OGG Vorbis. https://github.com/user-attachments/assets/4167bda4-63b5-4dc0-a7b2-694a9e3d3201 ## Why It's Good For The Game Back in 2022, I was one of the major proponents for adding such a change to the game. This is for a few reasons: * It doesn't really make human sense for a station to have hallways/spaces that you can enter and then just get completely trapped in. The station is a deathtrap because of _who_ is on it, not because it _is_ a death trap. I have always maintained that we should assume that the station is competently made to give the hijinx a much more jarring background. To me, maintenance isn't old sections of a station (although it can have those elements), but vital side pathways in the event of emergencies, like having extra fire stairs in a building. The doors to those fire stairs are always unlocked because they need to ensure that people are able to efflux to save themselves from danger rather than die. * It was easily subvertable anyways. You can easily ask the HoP for maintenance access or AI to let you out of maintenance (although the latter was a bit harder to articulate). I don't find myself agreeing with this as much nowadays but I remember the frustration I felt waiting for minutes for someone to open the door had something occurred for me to have found myself in maintenance. It's simply not fun and doesn't make sense for a station to have this. * I thought that it added a unique element to antagonism. You can't drag someone in maintenance and then have the whole entire subsection of the station be your den. It's important for you to secure your base should you be dragging people in there instead of just always being able to win via dragging. * People tend to forget this point, but it actually did cause a lot _more_ deaths in situations where threats originate outside the station/in maintenance. It was much easier for the killy-stabby mass murderers to ingress into main hallways and get to killing faster. This is why the change felt "equal" in a way. ### Why not remove it outright? I believe that a lot of balance changes over the last 3.5 years (30000 issues ago!) have been weighting for these interactions, and I think removing it all cold-turkey like will cause a huge upturn in deadliness and just not be what players are looking for in the new game loop. To me, this was a vital step in getting more towards 90-minute rounds, and I think we would see a drop in that. I also have those above three reasons that I am still a firm believer in, but I am still interested in seeing what a different system might entail and how that could play out. I added stat gathering so after we get 4-6 weeks of data, we can determine to keep or shelve this feature. I will probably always be on the "blocking" side of removing it outright unless there's some severe data that can convince me (which will probably need it's own test-merged PR, while this is meant to be added into the game right now). ### Why are we changing it? I think not enough people are dying. I played a few rounds yesterday and while a decent chunk of people were dying, I saw a few follies in my original line of thought. Maintenance should be a bit creepier and not auxiliary hallways (in normal circumstances), I already thought we did a really good job of that but I noticed that it wasn't as good as memory served me. I think maintenance should have a little bit more difficulty to navigate (i.e. if you're being chased down by someone and it's taking 2.5 seconds to open, that would be an excellent heart-pounding tension moment) and would overall be more interesting than the status quo. It is a bit sillier to me but some IRL buildings do have to have you hold down the push bar for a few seconds until it disengages, so this is agreeable. I also don't think the unidirectional exit design flow standards are where they were due to drift in application, so this is also a better way to uniformly apply it. ## Changelog 🆑 balance: After noticing it was too easy for animals to crawl through maintenance by abusing the Easy-Exit sensors, Nanotrasen has replaced all unrestricted door sensors (like in maintenance) with a pull-down lever that should take around 2-3 seconds to engage. It has been designed to allow the employee to actuate it despite any pressure differentials within an area. balance: The above change does not apply to select doors in the medical section of the station, which will continue to use the "older" Ready-Exit system. sound: In order to ensure that staff in high-traffic areas don't go bonkers due to this new change, sound dampeners have been installed to prevent the hydraulics from being heard for super long distances. However, they skimped out on the quality for the ones in maintenance... /🆑 FYI Mappers/Tweakers: This PR replaces all station map unres mapping helpers with the new subtype. You are welcome to replace certain doors with the old helper (the base type) to get the old behavior as you see fit, just explain why that behavior is desired in that location. Otherwise, it would be appreciated if we have this new behavior >95% of the time. |
||
|
Ghom
|
0b0c5ea91e |
Unit test material checks are now performed on all crafting recipes by default. All stack recipes now transfer mats to the results (#92620)
## About The Pull Request Extends the part of the crafting unit test that ensures consistency between the total mats of the components of a recipe (or rather, the result of said recipe) and a generic instance of the same type as its result, previously only implemented on food recipes. ## Why It's Good For The Game This ensures a degree of consistency with the material composition of various objects in the game. I couldn't do it in the original PR as that one was too big already and it took months to get it merged, and have the relative bugs fixed. Currently a WIP as I slowly deal with the unit test reports. ## Changelog 🆑 refactor: Follow-up to the crafting/material refactor from months ago. All objects crafted with stacks now inherit their mat composition (not necessarily the effects and color) by default, while previously only a few things like chair, sinks and toilets did. Report any object looking or behaving weirdly as a result. fix: The material composition of ammo boxes is no longer a 1/10 of what it's supposed to be. It was a shitty hack to make it harder to recycle empty ammo boxes. Instead, they lose materials as they're emptied now. /🆑 |
||
|
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 |
||
|
Leland Kemble
|
348789fa8d |
The Renamening- upgrades UNIQUE_RENAME and moves a lot of renaming implementations under it (#93115)
## About The Pull Request Moves a lot of the unique renaming implementations described in #82664 to the functions given by the `obj_flag` `UNIQUE_RENAME`. `UNIQUE_RENAME` has been given new properties to account for non-standard renaming, these being the `RENAME_NO_DESC` flag that prevents changing the description, the `nameformat()` and `descformat()` procs that, when modified, allow for applying naming formats(i.e. "Body Bag - [input]"), as well as other post-renaming handling such as changing the name of the output plant of a renamed seed, the `rename_checks()` proc that allows for unique naming prevention(such as a locked personal closet), and the `rename_reset()` proc to clean up other possible renamed variables potentially changed in `nameformat()` and `descformat()`. This also adds `/datum/element/tool_renaming` to crayons, which will let them rename anything that has `UNIQUE_RENAME`. I looked through everything with that flag, and I didn't see anything that I don't think should be renameable by a crayon(except things that shouldn't be renamable with pens), so it shouldn't fuck anything up. ## Why It's Good For The Game moves all of the non-honorable mentions in #82664 to the same renaming system, and also moves all of the honorable mentions save for: - plaques, as they only get renamed once and wouldn't benefit from `UNIQUE_RENAME` imo - books, because they're far more than just renaming, and are persistent - paintings, because they're persistent - photos, because they're not normal renaming and they're persistent - endoskeletons, because they're done with a multitool in UI - cardboard IDs, because they're far more than just renaming Additionally, this fixes: - Implanter renaming didn't work because a ! was missing - Clown borg picket sign renaming didn't work because they didn't use the correct arguments This'll make it easier to make renameable objects in the future, as well. ## Changelog 🆑 fix: fixes implanter renaming not working fix: fixes clownborg picket sign renaming not working code: brought most unique renaming implementations under UNIQUE_RENAME /🆑 |
||
|
Ghom
|
a28575aa82 |
[NO GBP] Fixing more issues with sand (you can make sand walls again, also ghost glass sheets?) (#93215)
## About The Pull Request Apparently wall construction code is snowflaked and indented as fuck (and the same goes for door assemblies). I'm not bothering refactoring everything with them, only to reduce the indentation, changing a couple vars and overall making it easier to work with them later. This includes wall construction not being hardcoded to sheets but include the possibility to use other kind of stacks as well (if you don't count the snowflake interaction with iron rods). In layman's terms, this means you can make walls made out of sand (distinct from sandstone) again. Also I've done some small changes to the materials storage, so that it can eject ores too if the material doesn't have a sheet type. Also, I've been told there may be issues with broken, uninteractable (probably not properly initialized) glass sheets beside the ORM. I'm not 100% sure about the deets, but it may have something to do with spawning the glass on the same turf the ORM is listening to, when smelting sand, causing some race conditions, so let's spawn it in nullspace ## Why It's Good For The Game While I'm sure there may be more elegant solutions (just take a look at the wall and door construction code, they both use text2path oh god!), I'm just here to make things a lil' cleaner and be done with issues with the fact that sand is made of sand. ## Changelog 🆑 fix: You can once again make sand walls. fix: Deconstructing an autolathe with sand in it should now drop sand. /🆑 |
||
|
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. /🆑 |
||
|
tmyqlfpir
|
010ee7b40e |
Fix airlock shell for circuit camera component (#87837)
## About The Pull Request This PR resolves an issue relating to circuit cameras and airlock shells. Fixes #84650 ## Why It's Good For The Game This is a bug fix, and makes airlock shells actually usable. ## Changelog 🆑 fix: Airlock shells are properly assigned circuit cameras modules /🆑 |
||
|
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 /🆑 |
||
|
san7890
|
a4328ae1f9 |
Audits tgui_input_text() for length issues (#86741)
Fixes #86784
## About The Pull Request
Although some of the issues found were a direct result from #86692
(
|
||
|
tgstation-ci[bot]
|
9a9b428b61 |
Wallening Revert [MDB Ignore][IDB Ignore] (#86161)
This PR is reverting the wallening by reverting everything up to
|
||
|
LemonInTheDark
|
4b4e9dff1d |
Wallening [IDB IGNORE] [MDB IGNORE] (#85491)
## What's going on here Kept you waitin huh! This pr resprites most all walls, windows and other "wall adjacent" things to a 3/4th perspective, technical term is "tall" walls (we are very smart). If you're trying to understand the technical details here, much of the "rendering tech" is built off the idea of split-vis. Basically, split a sprite up and render it on adjacent turfs, to prevent seeing "through" walls/doors, and to support seeing "edges" without actually seeing the atom itself. Most of the rest of it is pipelining done to accommodate how icons are cut. ## Path To Merge Almost* all sprites and code is done at this point. There are some things missing both on and off the bounty list, but that will be the case forever unless we force upstream (you guys) to stop adding new shit that doesn't fit the style. I plan on accepting and integrating prs to the current working repo <https://github.com/wall-nerds/wallening> up until a merge, to make contribution simpler and allow things like bounties to close out more easily This pr is quite bulky, even stripping away map changes it's maybe 7000 LOC (We have a few maps that were modified with UpdatePaths, I am also tentatively pring our test map, for future use.) This may inhibit proper review, although that is part of why I am willing to make it despite my perfectionism. Apologies in advance. Due to the perspective shift, a lot of mapping work is going to need to be done at some point. This comes in varying levels of priority. Many wallmounts are offset by hand, some are stuck in the wall/basically cannot be placed on the east/west/north edges of walls (posters), some just don't look great good in their current position. Tests are currently a minor bit yorked, I thought it was more important to get this up then to clean them fully. ## What does it look like?       ## Credits <details> <summary>Historical Mumbojumbo</summary> I am gonna do my best to document how this project came to be. I am operating off third party info and half remembered details, so if I'm wrong please yell at me. This project started sometime in late 2020, as a product of Rohesie trying to integrate and make easier work from Mojave Sun (A recently defunct fallout server) with /tg/. Mojave Sun (Apparently this was LITERALLY JUST infrared baron, that man is insane) was working with tall walls, IE walls that are 48px tall instead of the normal 32. This was I THINK done based off a technical prototype from aao7 proving A it was possible and B it didn't look like dogwater. This alongside oranges begging the art team for 3/4th walls (he meant TGMC style) lead to Rohesie bringing on contributors from general /tg/, including actionninja who would eventually take over as technical lead and Kryson, who would define /tg/'s version of the artstyle. Much of the formative aspects of this project are their work. The project was coming along pretty well for a few months, but ran into serious technical issues with `SIDE_MAP`, a byond map_format that allows for simpler 3/4th rendering. Due to BULLSHIT I will not detail here, the map format caused issues both at random with flickering and heavily with multiz. Concurrent with this, action stepped down after hacking out the rendering tech and starting work on an icon cutter that would allow for simpler icon generation, leaving ninjanomnom to manage the project. Some time passed, and the project stalled out due to the technical issues. Eventually I built a test case for the issues we had with `SIDE_MAP` and convinced lummox jr (byond's developer) to explain how the fuckin thing actually worked. This understanding made the project theoretically possible, but did not resolve the problems with multi-z. Resolving those required a full rework of how rendering like, worked. I (alongside tattle) took over project development from ninjanomnom at this time, and started work on Plane Cube (#69115), which when finished would finally make the project technically feasible. The time between then and now has been slow, progressive work. Many many artists and technical folks have dumped their time into this (as you can see from the credits). I will get into this more below but I would like to explicitly thank (in no particular order) tattle, draco, arcanemusic, actionninja, imaginos, viro and kylerace for keeping the project alive in this time period. I would have curled up into a ball and died if I had to do this all myself, your help has been indispensable. </details> <details> <summary>Detailed Credits</summary> Deep apologies if I have forgotten someone (I am sure I have, if someone is you please contact me). I've done my best to collate from the git log/my memory. Thanks to (In no particular order): Raccoff: Being funny to bully, creating threshold decals for airlocks aa07: (I think) inspiring the project ActionNinja: Laying the technical rock we build off, supporting me despite byond trying to kill him, building the icon cutter that makes this possible ArcaneMusic: Artistic and technical work spanning from the project's start to literally today, being a constant of motivation and positivity. I can't list all the stuff he's done Armhulen: Key rendering work (he's the reason thindows render right), an upbeat personality and a kick in the ass. Love you arm Azlan: Damn cool sprites, consistently Ben10Omintrix: You know ben showed up just to make basic mobs work, he's just fuckin like that man BigBimmer: A large amount of bounty work, alongside just like, throwing shit around. An absolute joy to work with Capsandi: Plaques, blastdoors, artistic work early on CapybaraExtravagante: Rendering work on wall frames Draco: SO MUCH STUFF. Much of the spritework done over the past two years is his, constantly engaged and will take on anything. I would have given up if not for you Floyd: Early rendering work, so early I don't even know the details. Enjoy freedom brother Imaginos16: A guiding hand through the middle years, handled much of the sprite review and contribution for a good bit there Iamgoofball: A dedication to detail and aesthetic goals, spends a lot of effort dissecting feedback with a focus on making things as good as they can be at the jump Infrared: Part of the impetus for the project, made all the xenomorph stuff in the MS style Jacquerel: A bunch of little upkeep/technical things, has done so much sprite gruntwork (WHY ARE THERE SO MANY PAINTING TYPES) Justice12354: Solved a bunch of error sprites (and worked out how to actually make prs to the project) Thanks bro! Kryson: Built the artstyle of the project, carrying on for years even when it was technically dying, only stopping to casually beat cancer. So much of our style and art is Kryson KylerAce: Handled annoying technical stuff for me, built window frame logic and fully got rid of grilles. LemonInTheDark: Rendering dirtywork, project management and just so much fucking time in dreammaker editing sprites Meyhazah: Table buttons, brass windows and alll the old style doors Mothblocks: Has provided constant support, gave me a deadline and motivation, erased worries about "it not being done", gave just SO much money to fill in the critical holes in sprites. Thanks moth MTandi: Contributed art despite his own blackjack and hookers club opening right down the road, I'm sorry I rolled over some of your sprites man I wish we had finished earlier Ninjanomnomnom: Consulted on gags issues, kept things alive through some truly shit times oranges: This is his fault Rohesie: Organized the effort, did much of the initial like, proof of concept stuff. I hope you're doin well whatever you're up to. san7890: Consulting on mapper UX/design problems, being my pet mapper Senefi: Offsetting items with a focus on detail/the more unused canidates SimplyLogan: Detailed map work and mapper feedback, personally very kind even if we end up talking past each other sometimes. Thank you! SpaceSmithers: Just like, random mapping support out of nowhere, and bein a straight up cool dude Tattle: A bunch of misc project management stuff, organizing the discord, managing the test server, dealing with all the mapping bullshit for me, being my backup in case of bus. I know you think you didn't do much but your presence and work have been a great help Thunder12345: Came out of nowhere and just so much of the random bounties, I'm kind of upset about how much we paid him Time-Green: I hooked him in by fucking with stuff he made and now he's just doin shit, thanks for helping out man! Twaticus: Provided artistic feedback and authority for my poor feeble coder brain, believed in the project for YEARS, was a constant source of ❤️ and affirmation unit0016: I have no god damn idea who she is, popped out of nowhere on the github one day and dealt with a bunch of annoying rendering/refactoring. Godspeed random furry thank you for all your effort and issue reports Viro: A bunch of detailed spriting moving towards 3/4ths, both on and off the wallening fork. If anyone believed this project would be done, it was viro Wallem: Artistic review and consultation, was my go-to guy for a long time when the other two spritetainers were inactive Waltermeldon: Cracked out a bunch of rendering work, he's the reason windows look like not dogwater. Alongside floyd and action spent a TON of time speaking to lummox/unearthing how byond rendering worked trying to make this thing happen ZephyrTFA: Added directional airlock helpers, dealt with a big fuckin bugaboo that was living in my brain like it was nothing. Love you brother And finally: The Mojave Sun development team. They provided a testbed for the idea, committed hundreds and hundreds of hours to the artstyle, and were a large reason we caught issues early enough to meaningfully deal with them. Your work is a testament to what longterm effort and deep detailed care produce. I hope you're doing well whatever you're up to. Go out with a bang! </details> ## Changelog 🆑 Raccoff, aa07, ActionNinja, ArcaneMusic, Armhulen, Azlan, Ben10Omintrix, BigBimmer, Capsandi, CapybaraExtravagante, Draco, Floyd, Iamgoofball, Imaginos16, Infrared, Jacquerel, Justice12354, Kryson, KylerAce, LemonInTheDark, Meyhazah, Mothblocks, MTandi, Ninjanomnom, oranges, Rohesie, Runi-c, san7890, Senefi, SimplyLogan, SomeAngryMiner, SpaceSmithers, Tattle, Thunder12345, Time-Green, Twaticus, unit0016, Viro, Waltermeldon, ZephyrTFA with thanks to the Mojave Sun team! add: Resprites or offsets almost all "tall" objects in the game to match a 3/4ths perspective add: Bunch of rendering mumbo jumbo to make said 3/4ths perspective work /🆑 --------- Co-authored-by: Jacquerel <hnevard@gmail.com> Co-authored-by: san7890 <the@san7890.com> Co-authored-by: = <stewartareid@outlook.com> Co-authored-by: Capsandi <dansullycc@gmail.com> Co-authored-by: ArcaneMusic <hero12290@aol.com> Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com> Co-authored-by: SomeAngryMiner <53237389+SomeAngryMiner@users.noreply.github.com> Co-authored-by: KylerAce <kylerlumpkin1@gmail.com> Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com> Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com> Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com> Co-authored-by: Runi-c <5150427+Runi-c@users.noreply.github.com> Co-authored-by: Roryl-c <5150427+Roryl-c@users.noreply.github.com> Co-authored-by: tattle <article.disaster@gmail.com> Co-authored-by: Senefi <20830349+Peliex@users.noreply.github.com> Co-authored-by: Justice <42555530+Justice12354@users.noreply.github.com> Co-authored-by: BluBerry016 <50649185+unit0016@users.noreply.github.com> Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: SimplyLogan <47579821+loganuk@users.noreply.github.com> Co-authored-by: Emmett Gaines <ninjanomnom@gmail.com> Co-authored-by: Rob Bailey <github@criticalaction.net> Co-authored-by: MMMiracles <lolaccount1@hotmail.com> |
||
|
SmArtKar
|
4ac4375faf |
Adds pen clicking, changes most pen typechecks into writing implement checks (#84186)
## About The Pull Request Fixes #84170 Adds pen clicking and changes some of edagger and pendriver code to use it instead. Also replaces most pen typechecks to writing implement checks where it makes sense, so now you can rename things with everything you can write with (crayons)  Twisting pen caps (for traitor uplinks) has been moved to ctrl + click instead. |
||
|
lessthanthree
|
30b9245adc |
Tram door fixes (#83672)
## About The Pull Request - Fixes the emergency open spamming infinitely on bump open - Tram doors have an associated assembly, can be repaired, rebuilt, and constructed - Adjusted door timings to better match the animation, no longer getting briefly stuck on an invisible, open door ## Why It's Good For The Game Fixing little issues that have surfaced ## Changelog 🆑 LT3 fix: Tram doors can now be constructed and assemblies built fix: Emergency opening tram doors no longer spam balloon alerts fix: Tram doors open faster on arrival fix: Tram doors correctly force close on attempt 3 /🆑 |
||
|
_0Steven
|
22677c338e |
Fix airlock assembly renaming examine grammar issue (#83365)
## About The Pull Request At some point the examine line about what the resulting airlock will be named got split off into a separate statement, but in the process some things got crossed and it doubled up on the final half of the line. Currently, an airlock might state: > There is a small <i>paper</i> placard on the assembly labelled ", written on it is 'Public Garden'". So we cut out the ` labelled \"[doorname]\"` part and go back to just having the `, written on it is '[created_name]'` part. > There is a small <i>paper</i> placard on the assembly, written on it is 'Public Garden'. ## Why It's Good For The Game Comprehensible examine for airlock assemblies. ## Changelog 🆑 spellcheck: Examining a renamed airlock assembly no longer says it has a paper placard that is "labelled with written on it is". /🆑 |
||
|
Jeremiah
|
1443ef79d3 |
Replaces a number of deciseconds into SECONDS (#82436)
## About The Pull Request Using these search regexes: Number ending in 0: `do_after\((\w+), (\d+)0,` Replace: `do_after($1, $2 SECONDS,` Single digit number: `do_after\((\w+), [1-9],` replace: `do_after($1, 0.$2 SECONDS,` Double: `do_after\((\w+), (\d)([1-9]),` Replace: `do_after($1, $2.$3 SECONDS,` ## Why It's Good For The Game Code readability |
||
|
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> |
||
|
13spacemen
|
8477939176 |
fixes inability to create material airlocks (#81711)
## About The Pull Request Fixes https://github.com/tgstation/tgstation/issues/81710 runtime due to parent proc not returning the airlock also added an update_appearance() ## Changelog 🆑 fix: You can build material airlocks again /🆑 |
||
|
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. |
||
|
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> |
||
|
SyncIt21
|
30b111114f |
Fixes some construction bugs with airlocks & windoors (#78261)
## About The Pull Request 1. Fixes #77981. the airlock electronics `unres_sides` and `unres_sensor` vars were not copied onto the windoor after its construction was finished manually without RCD. Now a windoor assembly is spawned and it is finished by the RCD just like you would do manually 2. Windoors created via RCD did not have any electronics installed inside them. It would only copy the `access` and `passed_name` vars onto the windoor, leaving its `electronics` var blank. It's also fixed by the windoor assembly 3. Airlocks constructed via RCD now uses the `finish_door()` proc of an airlock assembly to correctly complete an airlock. This proc does important stuff such as adding the `/datum/component/shell` component when the airlock electronics requests shell control and the RCD was skipping over these steps. That's fixed now too ## Changelog 🆑 fix: Manually constructed windoors have correct unrestricted accesses applied to them fix: Windoors created via RCD now actually have electronics inside them fix: Airlocks constructed via RCD have the shell component correctly installed inside them and have no other missing variables /🆑 |
||
|
lessthanthree
|
bb4792cc0d |
Fix invisible box on rotated multi-tile airlocks (#77736)
## About The Pull Request Fixes airlock bounding box being incorrect when rotated leading to a solid, invisible box on the adjacent tile. Icon states match airlock direction. ## Changelog 🆑 LT3 fix: Rotated multi-tile airlocks display correctly and won't create an invisible box next to itself /🆑 |
||
|
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. /🆑 |
||
|
lessthanthree
|
635bae421f |
Multi-tile airlock assemblies/pathing [NO GBP] (#77537)
## About The Pull Request Small fixes after https://github.com/tgstation/tgstation/pull/76732 - Creates base large subtype for mapping - Door assembly naming consistent with other airlocks - Base subtype large airlock no longer spawns in a normal sized airlock - Renames station2 subtype to public for consistency ## Changelog 🆑 LT3 fix: Base large airlock subtype no longer spawns a normal sized airlock image: Added mapping icons for large airlocks code: Repathed all public airlocks to consistent naming /🆑 |
||
|
lessthanthree
|
ed2c74c8b3 |
Multi-tile airlocks (#76732)
## About The Pull Request Makes the large glass airlock operate properly on both tiles instead of being a single tile airlock with a larger icon. ## Why It's Good For The Game The right side of the current large glass airlock isn't really an airlock tile, so any procs that check for the airlock's turf don't work on the right side of the airlock. <details> <summary>Video</summary> After: https://github.com/tgstation/tgstation/assets/83487515/5bd571b5-fc9c-4135-942b-b712ae9ec960 Before: https://github.com/tgstation/tgstation/assets/83487515/e752c085-e663-468b-ac21-2ae5d230b4be </details> ## Changelog 🆑 LT3 fix: Large airlocks are now a subtype and function on both tiles /🆑 --------- Co-authored-by: san7890 <the@san7890.com> Co-authored-by: Jacquerel <hnevard@gmail.com> |
||
|
Couls
|
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 /🆑 |
||
|
LemonInTheDark
|
23bfdec8f4 |
Multiz Rework: Human Suffering Edition (Contains PLANE CUBE) (#69115)
About The Pull Request I've reworked multiz. This was done because our current implementation of multiz flattens planes down into just the openspace plane. This breaks any effects we attach to plane masters (including lighting), but it also totally kills the SIDE_MAP map format, which we NEED for wallening (A major 3/4ths resprite of all wall and wall adjacent things, making them more then one tile high. Without sidemap we would be unable to display things both in from of and behind objects on map. Stupid.) This required MASSIVE changes. Both to all uses of the plane var for reasons I'll discuss later, and to a ton of different systems that interact with rendering. I'll do my best to keep this compact, but there's only so much I can do. Sorry brother. Core idea OK: first thing. vis_contents as it works now squishes the planes of everything inside it down into the plane of the vis_loc. This is bad. But how to do better? It's trivially easy to make copies of our existing plane masters but offset, and relay them to the bottom of the plane above. Not a problem. The issue is how to get the actual atoms on the map to "land" on them properly. We could use FLOAT_PLANE to offset planes based off how they're being seen, in theory this would allow us to create lens for how objects are viewed. But that's not a stable thing to do, because properly "landing" a plane on a desired plane master would require taking into account every bit of how it's being seen, would inherently break this effect. Ok so we need to manually edit planes based off "z layer" (IE: what layer of a z stack are you on). That's the key conceit of this pr. Implementing the plane cube, and ensuring planes are always offset properly. Everything else is just gravy. About the Plane Cube Each plane master (except ones that opt out) is copied down by some constant value equal to the max absolute change between the first and the last plane. We do this based off the max z stack size detected by SSmapping. This is also where updates come from, and where all our updating logic will live. As mentioned, plane masters can choose to opt out of being mirrored down. In this case, anything that interacts with them assuming that they'll be offset will instead just get back the valid plane value. This works for render targets too, since I had to work them into the system as well. Plane masters can also be temporarily hidden from the client's screen. This is done as an attempt at optimization, and applies to anything used in niche cases, or planes only used if there's a z layer below you. About Plane Master Groups BYOND supports having different "maps" on screen at once (IE: groups of items/turfs/etc) Plane masters cannot cover 2 maps at once, since their location is determined by their screen_loc. So we need to maintain a mirror of each plane for every map we have open. This was quite messy, so I've refactored it (and maps too) to be a bit more modular. Rather then storing a list of plane masters, we store a list of plane master group datums. Each datum is in charge of the plane masters for its particular map, both creating them, and managing them. Like I mentioned, I also refactored map views. Adding a new mapview is now as simple as newing a /atom/movable/screen/map_view, calling generate_view with the appropriate map id, setting things you want to display in its vis_contents, and then calling display_to on it, passing in the mob to show ourselves to. Much better then the hardcoded pattern we used to use. So much duplicated code man. Oh and plane master controllers, that system we have that allows for applying filters to sets of plane masters? I've made it use lookups on plane master groups now, rather then hanging references to all impacted planes. This makes logic easier, and prevents the need to manage references and update the controllers. image In addition, I've added a debug ui for plane masters. It allows you to view all of your own plane masters and short descriptions of what they do, alongside tools for editing them and their relays. It ALSO supports editing someone elses plane masters, AND it supports (in a very fragile and incomplete manner) viewing literally through someone else's eyes, including their plane masters. This is very useful, because it means you can debug "hey my X is yorked" issues yourself, on live. In order to accomplish this I have needed to add setters for an ungodly amount of visual impacting vars. Sight flags, eye, see_invis, see_in_dark, etc. It also comes with an info dump about the ui, and plane masters/relays in general. Sort of on that note. I've documented everything I know that's niche/useful about our visual effects and rendering system. My hope is this will serve to bring people up to speed on what can be done more quickly, alongside making my sin here less horrible. See https://github.com/LemonInTheDark/tgstation/blob/multiz-hell/.github/guides/VISUALS.md. "Landing" planes Ok so I've explained the backend, but how do we actually land planes properly? Most of the time this is really simple. When a plane var is set, we need to provide some spokesperson for the appearance's z level. We can use this to derive their z layer, and thus what offset to use. This is just a lot of gruntwork, but it's occasionally more complex. Sometimes we need to cache a list of z layer -> effect, and then use that. Also a LOT of updating on z move. So much z move shit. Oh. and in order to make byond darkness work properly, I needed to add SEE_BLACKNESS to all sight flags. This draws darkness to plane 0, which means I'm able to relay it around and draw it on different z layers as is possible. fun darkness ripple effects incoming someday I also need to update mob overlays on move. I do this by realiizing their appearances, mutating their plane, and then readding the overlay in the correct order. The cost of this is currently 3N. I'm convinced this could be improved, but I've not got to it yet. It can also occasionally cause overlays to corrupt. This is fixed by laying a protective ward of overlays.Copy in the sand, but that spell makes the compiler confused, so I'll have to bully lummy about fixing it at some point. Behavior changes We've had to give up on the already broken gateway "see through" effect. Won't work without managing gateway plane masters or something stupid. Not worth it. So instead we display the other side as a ui element. It's worse, but not that bad. Because vis_contents no longer flattens planes (most of the time), some uses of it now have interesting behavior. The main thing that comes to mind is alert popups that display mobs. They can impact the lighting plane. I don't really care, but it should be fixable, I think, given elbow grease. Ah and I've cleaned up layers and plane defines to make them a bit easier to read/reason about, at least I think. Why It's Good For The Game <visual candy> Fixes #65800 Fixes #68461 Changelog cl refactor: Refactored... well a lot really. Map views, anything to do with planes, multiz, a shit ton of rendering stuff. Basically if you see anything off visually report it admin: VV a mob, and hit View/Edit Planes in the dropdown to steal their view, and modify it as you like. You can do the same to yourself using the Edit/Debug Planes verb /cl |
||
|
Watermelon914
|
69226b3bd7 |
Drastically improved the USB connection for air alarms. Any airlock can now be made into a shell (#68632)
The USB connections for air alarms have been improved and now include scrubber control, vent control and the setting of the air alarm mode. Also fixes a bug where the limits were not being properly set. The scrubber, vent and limit control can be duplicated in the circuit to allow multiple limits/scrubbers/vents to be controlled by one circuit. Any airlock can be made into a shell during construction by configuring the airlock electronic before insert. |
||
|
Fikou
|
01838b14a6 |
you no longer rename door assemblies with pens on combat mode (#68550)
what the title says it makes you able to break door assembles with an energy dagger |
||
|
san7890
|
ea6755b511 |
Abusing Generosity - Unrestricted Airlock Access Flip (#68096)
* Abusing Generosity - Unrestricted Airlock Access Flip Hey there, We now have a lot of unrestricted access helpers on airlocks, which are neato. However, while spitballing ideas in regards to this a few months ago, someone suggested to make it such that you can use the airlock wires to "flip" the directional way. I decided to sit down and code it in today. The high details are this: You can only do it if the airlock has a directional Request-to-Exit sensor (which is just a thing I made up, you can't get this in-game outside of mapping it in via a directional helper). You can tell if a door has it the same way you can tell if any door is a directional door, or you can simply just check to see if the Unrestricted Access Display is "on" in any capcity (the airlock will not have the sensor if the display is off). It's effectively a dud without the "sensor". However, if it does have it, you can either pulse it (to switch the direction by 180 degrees) or cut the wire (to disable the direction entirely). When you mend the wire though, it'll activate to a random direction (could even be inside a wall). You can keep cutting and mending until you get what you want, though. If it gets stuck in a wall though... shouldn't have cut it. While in the area, I alphabetized a bunch of lists, added a new color of airlock wire, and probably some other stuff. * Adds this behavior to building new airlocks I also renamed it to "sensor" so it's a bit clearer across all the potential contexts. It does seem to handle setting multiple directions on creating a new mapload, cutting/pulsing will condense the nice multi-directional stuff into one direction (i am okay with this). Co-authored-by: spookydonut <github@spooksoftware.com> Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com> |
||
|
Iamgoofball
|
ba0ef6d3fb |
Fixes mid-construction airlocks having paper stuck to them (#67530)
Fixes #67393 |
||
|
Son-of-Space
|
e3fd627615 |
[MDB IGNORE] The Grand Airlock Naming Audit (#67235)
I manually audited all 4,710 instances of airlocks across all maps for upper casing You'll never guess what I found. UPDATE: We now have a grep to check for mistitled airlocks, and it's in this PR! |
||
|
Y0SH1M4S73R
|
e657e6c4f7 |
Most materials can be used to build most things (#66181)
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
GoblinBackwards
|
f0559c8e7e | checks if airlock type actually exists (#65494) | ||
|
Jeremiah
|
9c6fdb567d |
TGUI list conversions + bug fixes (#63354)
About The Pull Request
Converts more inputs to TGUI. Possibly all user-facing input lists in the game.
Did any surrounding text/number inputs as well
Added null choice support so users can press cancel.
Added some misc TGUI input fixes
Fixed custom vendors while I was there
I refactored a lot of code while just poking around.
Primarily, usage of .len in files where I was already working on lists.
Some code was just awful - look at guardian.dm and its non use of early returns
If there are any disputes, I can revert it just fine, those changes are not integral to the PR.
Why It's Good For The Game
Fixes #63629
Fixes #63307
Fixes custom vendors /again/
Text input is more performant.
Part of a long series of TGUI conversion to make the game more visually appealing
Changelog
cl
refactor: The majority of user facing input lists have been converted to TGUI.
refactor: Tgui text inputs now scale with entered input.
fix: Many inputs now properly accept cancelling out of the menu.
fix: Fixes an edge case where users could not press enter on number inputs.
fix: Custom vendor bluescreen.
fix: You can now press ENTER on text inputs without an entry to cancel.
/cl
|
||
|
Jeremiah
|
d17a60fb53 |
TGUI input box conversions 2 (#63395)
More text inputs converted to tgui, TGUI text and number input now more sanely handles ENTER key being pressed, you can now press anywhere in the window to enter the input. TGUI text input now considers placeholder text for the default valid state. IE, if there is default text you can press enter immediately without having to rewrite it just to recheck validity. Fixes: useSharedState => useLocalState. not only was sharedstate not needed but it opened up the ui to vulnerabilities |
||
|
John Willard
|
6c0aba5da4 |
removes double spaces AFTER symbols (#62515)
* removes double spaces AFTER symbols * found more |
||
|
tralezab
|
6c01cc2c01 |
every case of initialize that should have mapload, does (#61623)
## About The Pull Request stop forgetting to include mapload, if you don't include it then every single subtype past it by default doesn't include it for example, `obj/item` didn't include mapload so every single item by default didn't fill in mapload  ## Regex used: procs without args, not even regex `/Initialize()` procs with args `\/Initialize\((?!mapload)((.)*\w)?` cleanup of things i didn't want to mapload: `\/datum\/(.)*\/Initialize\(mapload` |
||
|
小月猫
|
605a3a660c |
The Cycling 2.0, Airlocks can now be built in game to cycle and named (#61226)
You can now edit an airlock control board (both physically and through an RCD) to set the airlock name and what ID it cycles on Airlocks now say what ID it cycles on when examined when an airlock is made it takes its circuits set name and ID and updates the cycling i redid how the cycle_id is updated on creation, so now when an airlock is made and grabbing airlocks with an identical ID to cycle it checks if the other airlocks with that ID needs a reference to the new airlock, and if so, it adds it, so you can add doors back to a cycle system if it breaks NOTE: unfortunately the way linear airlocks, like the small 2 door airlocks to space, set their links, you cannot repair their cycle this way, you will have to deconstruct the remaining door and rebuild both to cycle again |
||
|
Watermelon914
|
375a20e49b |
Refactors most spans into span procs (#59645)
Converts most spans into span procs. Mostly used regex for this and sorted out any compile time errors afterwards so there could be some bugs. Was initially going to do defines, but ninja said to make it into a proc, and if there's any overhead, they can easily be changed to defines. Makes it easier to control the formatting and prevents typos when creating spans as it'll runtime if you misspell instead of silently failing. Reduces the code you need to write when writing spans, as you don't need to close the span as that's automatically handled by the proc. (Note from Lemon: This should be converted to defines once we update the minimum version to 514. Didn't do it now because byond pain and such) |
||
|
TemporalOroboros
|
daec5002fc |
Adds Neon Carpet (#59140)
Adds a couple varieties of neon carpet. Makes decals care about their plane in addition to their layer. |
||
|
TemporalOroboros
|
e4079c87b8 |
update_appearance (#55468)
Creates update_name and update_desc Creates the wrapper proc update_appearance to batch update_name, update_desc, and update_icon together Less non-icon handling code in update_icon and friends Signal hooks for things that want to change names and descriptions 99%+ of the changes in this are just from switching everything over to update_appearance from update_icon |
||
|
Fikou
|
8d586a7cb0 |
Rename metal sheets to iron sheets (#56643)
It's a specific type of metal, it shouldnt just be called generic "metal". The reagent, ore and material datum are already called iron. |
||
|
TiviPlus
|
0eaab0bc54 |
Grep for space indentation (#54850)
#54604 atomizing Since a lot of the space indents are in lists ill atomize those later |
||
|
ShizCalev
|
4b6500fb67 |
Makes all anchored changes use setAnchored(), COMSIG_MOVABLE_SETANCHORED now only sent if an AM's anchored var has changed for more reliable usage. (#52254)
* Converts everything to use setAnchored() + other fixes * Fixed singulo debug * singulo again * forgot to move the vv_edit proc * caught that this time :) * changes * Update code/game/atoms_movable.dm Co-authored-by: Rohesie <rohesie@gmail.com> Co-authored-by: Rohesie <rohesie@gmail.com> |
||
|
cacogen
|
458b783d3c |
Change airlock assembly deletion cost to 16
Add the ability to delete firelock frames |
||
|
cacogen
|
fa685bb4be |
RCD can now deconstruct airlock assemblies
Get through the pile of work left by explosions slightly quicker. |
||
|
MrPerson
|
26093e5ac2 |
Further update_icon splitup (#48784)
* Further update_icon splitup After this there'll be just under 100 old update_icon() calls that need fixing. * Thanks Travis |
||
|
ShizCalev
|
35e4e6152b | Fixes airlocks reverting to normal versions if you added glass prior to the frame's mineral | ||
|
kingofkosmos
|
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'. |
