mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-08-22 04:30:44 +01:00
docker-build
30
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
27e868a3da |
Refactors how air sensors & atmos monitors connect (#92849)
## About The Pull Request **1. Qol** - Air sensors(maploaded & hand crafted) now auto connect to any input ports & output valves that are within a 4 tile radius from it meaning there is no need for these ports to have unique IDs attached to them & you don't need a multitool to link them together if you first placed those ports & then placed the air sensor close to them - Atmos control monitors now finds all air sensors that are closest to it within the same z level meaning you can have/place multiple air sensors of the same type on the same z level & the monitor will locate them correctly without any ambiguity **2. Refactor** - Removed var `chamber_id` from both injectors & vents meaning you don't need to have unique ids assigned to them. As long as mappers/players put them within 4 tile radius from the air sensor it will auto connect to them - Removed var `GLOB.map_loaded_sensors` ## Changelog 🆑 qol: hand crafted air sensors now auto connect to input & output ports if they are located within a 4 tile radius from it qol: atmos control monitors now locate all air sensors nearest to in on that same z level meaning you can have multiple air sensors of the same type on the same map refactor: refactored how air sensors & atmos monitors connect to each other. Please report any atmos computers that have missing input valves/output ports on their connected air sensors or those that don't list any air sensors at all on github /🆑 --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> |
||
|
SyncIt21andGitHub
|
ff13dcadab |
Stacks check for invalid amounts (#91656)
## About The Pull Request Alleviates #91603 As in it does not fix it because i have not been able to reproduce it. It now checks for invalid values and defaults to `amount`(which is 1) during `Initialize()` and not null so we don't have to pass the number `1` when creating a single sheet. A stack trace is thrown for <= 0 sheet amounts so we can debug & fix stuff ## Changelog 🆑 code: stacks error on invalid amounts, removed manual passing of number `1` when creating a single stack in many cases /🆑 |
||
|
|
cb51a652a9 |
Adds automatic GAGS icon generation for mapping and the loadout menu (#90940)
## About The Pull Request Revival of https://github.com/tgstation/tgstation/pull/86482, which is even more doable now that we have rustg iconforge generation. What this PR does: - Sets up every single GAGS icon in the game to have their own preview icon autogenerated during compile. This is configurable to not run during live. The icons are created in `icons/map_icons/..` - This also has the side effect of providing accurate GAGS icons for things like the loadout menu. No more having to create your own previews.  <details><summary>Mappers rejoice!</summary>   </details> <details><summary>Uses iconforge so it does not take up much time during init</summary>  </details> --- ### Copied from https://github.com/tgstation/tgstation/pull/86482 as this still applies: Note for Spriters: After you've assigned the correct values to vars, you must run the game through init on your local machine and commit the changes to the map icon dmi files. Unit tests should catch all cases of forgetting to assign the correct vars, or not running through init. Note for Server Operators: In order to not generate these icons on live I've added a new config entry which should be disabled on live called GENERATE_ASSETS_IN_INIT in the config.txt ## Why It's Good For The Game No more error icons in SDMM and loadout. ## Changelog 🆑 refactor: preview icons for greyscale items are now automatically generated, meaning you can see GAGS as they actually appear ingame while mapping or viewing the loadout menu. /🆑 --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> |
||
|
TimandGitHub
|
f7c53dec8e |
Fix air alarms to work correctly while connected to a gas sensor (#86958)
## About The Pull Request This fixes a bug that was hard to troubleshoot. While I was testing my other PR, I noticed that I was getting inconsistent atmos readouts while using a gas sensor hooked to an air alarm. Sometimes I would get the readout from the tile of the air alarm, and other times it would give me the readout of the gas sensor... I tracked it down and the root cause was the `COMSIG_TURF_EXPOSE` signal not being properly reassigned when a gas sensor was connected. My fix is to transfer the signal from the air alarm to the air sensor and vice versa when they are connected/disconnected. I also added some redundancies in place to limit air sensors to be only connected to one air alarm at a time. I threw in a mapping check to make sure one air alarm isn't linked to multiple sensors to catch some accidents. Another small fix is that air alarms now can be relinked to other air sensors if the sensor is reset. This was a problem for round-start linked air alarms that were paired with sensors since you could turn off or break a sensor and then the air alarm would have it's link severed without being able to link to any new sensors. ## Why It's Good For The Game Air alarms are becoming more robust! ## Changelog 🆑 fix: Fix air alarms to work correctly while connected to a gas sensor fix: Fix paired air alarms and sensors to be able to relink to other devices if turned off, reset, or destroyed. /🆑 |
||
|
tgstation-ci[bot]GitHubtgstation-ci <179393467+tgstation-ci[bot]@users.noreply.github.com>Jordan DominionGhomsan7890MrMelbert |
9a9b428b61 |
Wallening Revert [MDB Ignore][IDB Ignore] (#86161)
This PR is reverting the wallening by reverting everything up to
|
||
|
klorpaandGitHub
|
d2c7806047 |
Spelling and Grammar Fixes (#85992)
## About The Pull Request Fixes several errors to spelling, grammar, and punctuation. ## Why It's Good For The Game ## Changelog 🆑 spellcheck: fixed a few typos /🆑 |
||
|
John WillardandGitHub
|
1880003270 |
Reworks silicon/ai access checking & fixes some ui_act's (#84964)
## About The Pull Request Currently to check for Silicon access, we do: ``if is silicon or is admin ghost or has unlimited silicon privileges or has machine remote in hand`` What has unlimited silicon privileges? Bots, Drones, and admin ghosts. To check for AI access, it just checks for AI instead of silicon, and doesnt check for unlimited silicon privileges. This was kinda silly, so I thought I should make this a little easier to understand. Now all silicon/ai traits come from ``AI_ACCESS_TRAIT`` or ``SILICON_ACCESS_TRAIT``. I made a single exception to keep Admin ghost, since now instead of being a var on the client, we moved it to using the same trait but giving it to the client instead, but since we have to keep parity with previous functionality (admins can spawn in and not have this on, it only works while as a ghost), I kept previous checks as well. No more type checks, removes a silly var on the mob level and another on the client. Now while I was doing this, I found a lot of tgui's ``ui_act`` still uses ``usr`` and the wrong args, so I fixed those wherever I saw them, and used a mass replace for the args. Other changes: - machinery's ``ui_act`` from https://github.com/tgstation/tgstation/pull/81250 had ``isAI`` replaced with ``HAS_AI_ACCESS``, this has been reverted. Machine wands and admin ghosts no longer get kicked off things not on cameras. This was my fault, I overlooked this when adding Human AI. - Human AI's wand gives AI control as long as it's in your hand, you can swap to your offhand. I hope this doesn't end up going horribly, otherwise I'll revert this part. It should let human AIs not have their UI closed on them when swapping to eat food or use their door wand or whatnot. - Bots previously had special checks to scan reagents and be unobservant, I replaced this with giving them the trait. I also fixed an instance of unobservant not being used, so now statues don't affect the basic creature, whatever that is. ## Why It's Good For The Game This is an easier to understand way of handling silicon access and makes these mobs more consistent between eachother. Other than what I've mentioned above, this should have no impact on gameplay itself. ## Changelog 🆑 fix: Statues don't count as eyes to creatures. fix: Human AIs and Admin ghosts no longer get kicked off of machines that aren't on cameranets. /🆑 |
||
|
YesterdaysPromiseandGitHub
|
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. |
||
|
norsvenskaandGitHub
|
5f80128fa9 |
Corrects 200+ instances of "it's" where it should've been "its" instead (#85169)
## About The Pull Request it's - conjunction of "it" and "is" its - possessive form of "it" grammar is hard, and there were a lot of places where "it's" was used where it shouldn't have been. i went and painstakingly searched the entire repository for these instances, spending a few hours on it. i completely ignored the changelog archive, and i may have missed some outliers. most player-facing ones should be corrected, though ## Why It's Good For The Game proper grammar is good ## Changelog 🆑 spellcheck: Numerous instances of "it's" have been properly replaced with "its" /🆑 |
||
|
JollyandGitHub
|
365223d7bc |
[MDB IGNORE] Map lints the piping_layer var and scrubs it off our maps (#84686)
## About The Pull Request Title, continuation of #84385 ## Why It's Good For The Game Continuation of my previous PR, this time with the other var being banned and additional lint.  I also added new subtypes to the required atmos machinery that needed it. This'll add transparency to what layer a machine will be on and make it easier to set up pipe networks while mapping, instead of guessing "I hope this'll connect!". Nothing should break or go awry, I looked at some maps to make sure and they looked fine. Snowdin can also go rot, whoever did the pipenet there, I have a question, `why`. ## Changelog 🆑 Jolly code: Behind the scenes, atmos machines (freezers/mixers) in maps were tweaked a bit. If you see them no longer connected to specific pipenets, please make an issue report, this is not intended behavior!! /🆑 |
||
|
|
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> |
||
|
|
c1f11f26ce |
Converts arbitrary energy units to the joule. Fixes conservation of energy issues relating to charging cells. (#81579)
## About The Pull Request Removes all arbitrary energy and power units in the codebase. Everything is replaced with the joule and watt, with 1 = 1 joule, or 1 watt if you are going to multiply by time. This is a visible change, where all arbitrary energy units you see in the game will get proper prefixed units of energy. With power cells being converted to the joule, charging one joule of a power cell will require one joule of energy. The grid will now store energy, instead of power. When an energy usage is described as using the watt, a power to energy conversion based on the relevant subsystem's timing (usually multiplying by seconds_per_tick or applying power_to_energy()) is needed before adding or removing from the grid. Power usages that are described as the watt is really anything you would scale by time before applying the load. If it's described as a joule, no time conversion is needed. Players will still read the grid as power, having no visible change. Machines that dynamically use power with the use_power() proc will directly drain from the grid (and apc cell if there isn't enough) instead of just tallying it up on the dynamic power usages for the area. This should be more robust at conserving energy as the surplus is updated on the go, preventing charging cells from nothing. APCs no longer consume power for the dynamic power usage channels. APCs will consume power for static power usages. Because static power usages are added up without checking surplus, static power consumption will be applied before any machine processes. This will give a more truthful surplus for dynamic power consumers. APCs will display how much power it is using for charging the cell. APC cell charging applies power in its own channel, which gets added up to the total. This will prevent invisible power usage you see when looking at the power monitoring console. After testing in MetaStation, I found roundstart power consumption to be around 406kW after all APCs get fully charged. During the roundstart APC charge rush, the power consumption can get as high as over 2MW (up to 25kW per roundstart APC charging) as long as there's that much available. Because of the absurd potential power consumption of charging APCs near roundstart, I have changed how APCs decide to charge. APCs will now charge only after all other machines have processed in the machines processing subsystem. This will make sure APC charging won't disrupt machines taking from the grid, and should stop APCs getting their power drained due to others demanding too much power while charging. I have removed the delays for APC charging too, so they start charging immediately whenever there's excess power. It also stops them turning red when a small amount of cell gets drained (airlocks opening and shit during APC charge rush), as they immediately become fully charged (unless too much energy got drained somehow) before changing icon. Engineering SMES now start at 100% charge instead of 75%. I noticed cells were draining earlier than usual after these changes, so I am making them start maxed to try and combat that. These changes will fix all conservation of energy issues relating to charging powercells. ## Why It's Good For The Game Closes #73438 Closes #75789 Closes #80634 Closes #82031 Makes it much easier to interface with the power system in the codebase. It's more intuitive. Removes a bunch of conservation of energy issues, making energy and power much more meaningful. It will help the simulation remain immersive as players won't encounter energy duplication so easily. Arbitrary energy units getting replaced with the joule will also tell people more meaningful information when reading it. APC charging will feel more snappy. ## Changelog 🆑 fix: Fixes conservation of energy issues relating to charging powercells. qol: APCs will display how much power they are using to charge their cell. This is accounted for in the power monitoring console. qol: All arbitrary power cell energy units you see are replaced with prefixed joules. balance: As a consequence of the conservation of energy issues getting fixed, the power consumption for charging cells is now very significant. balance: APCs only use surplus power from the grid after every machine processes when charging, preventing APCs from causing others to discharge while charging. balance: Engineering SMES start at max charge to combat the increased energy loss due to conservation of energy fixes. /🆑 --------- Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
MrMelbertandGitHub
|
1e76fd70b4 |
Attack chain refactoring: Broadening tool_act into item_interact, moving some item interactions to... atom/item_interact / item/interact_with_atom (#79968)
## About The Pull Request Implements half of this (with some minor changes):  The ultimate goal of this is to split our attack chain in two: - One for non-combat item interactions - Health analyzer scanning - using tools on stuff - surgery - Niche other interactions - One for combat attacking - Item hit thing, item deal damage. - Special effects on attack would go here. This PR begins this by broadining tool act into item interact. Item interact is a catch-all proc ran at the beginning of attack chain, before `pre_attack` and such, that handles the first part of the chain. This allows us to easily catch item interaction and cancel the attack part of the chain by using deliberate bitflag return values, rather than `TRUE` / `FALSE`*. *Because right now, `TRUE` = `cancel attack`, no matter what, which is unclear to people. Instead of moving as much as possible to the new proc in this PR, I started by doing some easy, obvious things. More things can be moved in the future, or technically they don't even need to move in a lot of cases. ## Changelog 🆑 Melbert refactor: Refactored some methods of items interacting with other objects or mobs, such as surgery and health analzyers. Report if anything seems wrong /🆑 |
||
|
san7890andGitHub
|
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. |
||
|
|
e312613fa6 |
Vents & Injectors now link properly with air sensors via multitool both ways (#78238)
## About The Pull Request If you first log a unary vent/injector in an multitool and then link it with an air sensor(i.e. you invoke the air sensors multitool_act) everything works correctly. But if you first log a air sensor in an multitool and then link it with an unary vent/injector (i.e. you invoke the vents/injectors multitool_act), the vent gets set up incorrectly i.e., its output pressure, operating mode is not set and it does not function. This PR fixes that ## Changelog 🆑 fix: Unary vents & Injectors now link properly with air sensors via multitool both ways /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
FikouandGitHub
|
b77c1c85ea |
MODLink System (+ NWTLMM) (#77639)
## About The Pull Request A pact made with `@Kapu1178` Small changes you should not care about: RD MODsuit outfit (admin only) no longer has a beret that blocks the activation of the suit The beret used by death squad officers no longer is blocked from being put on a hat stabilizer module Admins can now Shear matrices of objects in Modify Transform Multitool buffers have been a little refactored to use a setter proc that saves them from causing hard dels Cooler stuff: A revival and remake of [Nobody Wants To Learn Matrix Math](https://github.com/tgstation/tgstation/pull/59103), this time with additional tooling for quick matrix calculations.  The MODLink system, available through every MODsuit and MODLink scryers (a neck item obtainable from advanced modsuit research or charliestation) Let's you make a holographic call with any other MODLink user, where you can chat in realtime and see what's up with em   ## Why It's Good For The Game Adds a fun way for the crew to communicate with each other that can be done in real-time with relative privacy compared to radio. ## Changelog 🆑 Fikou, Armhulen, Sheets (+rep for Mothblocks and Potato) fix: RD MODsuit outfit (admin only) no longer has a beret that blocks the activation of the suit fix: The beret used by death squad officers no longer is blocked from being put on a hat stabilizer module admin: Admins can now Shear matrices of objects in Modify Transform admin: Admins now have access to Test Matrices in the VV dropdown, an all-in-one tool for editing transforms. add: MODLink system, available through scryers (from RnD and Charlie Station) and through MODsuits. Lets you call people with holographs! /🆑 |
||
|
|
a373b4cb08 |
Icon folder cleaning wave one (#76703)
## About The Pull Request Due to a mental breakdown caused by unfathomable abomination that is icons folder, I swore to myself to one day clean it. Today is kind of that day. Been at it for around 6, you gotta understand I need a rest. I tracked most changes in descriptions of commits if you are looking for details. ## Why It's Good For The Game Saner spriters make better sprites. And also, just helps keep track of things. ## Changelog 🆑 image: added sprites for different variants of scrolls. image: modified couple posters with ghost pixels. /🆑 --------- Co-authored-by: OrionTheFox <76465278+OrionTheFox@users.noreply.github.com> |
||
|
|
903eea5a69 |
Air Sensor are Craftable, Removed from RPD UI, Have New Linking System (#75869)
## About The Pull Request **1. Craftable & Removed from RPD UI** 1. Air sensor's are now craftable 2. You can turn them on/off with hand. Even though turning off the sensor will change it to a diffrent type[from `obj/machinery/air_sensor` -> `obj/item/air_sensor`] it's I/O port's are sill preserved when turning them on although you have to assign it a new name again which is usefull if you want to change the sensor's purpose in game. 3. They can now only be deconstructed by a welding tool and should be wrenched in place to turn them on. 4. Turned off air sensor's once unwrenched can be picked up like any regular item 5. Air sensor's are removed from the RPD UI because they don't go with pipes so it logically doesn't make sense to group them with pipe related device's Removed unused code in the process https://github.com/tgstation/tgstation/assets/110812394/3439a0f3-9c48-43ac-8f4b-98135435ec13 **2. New ID System** The problem with air sensor's is that each sensor is assigned a unique ID which is then stored in `GLOB.objects_by_id_tag` list. Each sensor name it's assigned based on the gas it's trying to sense(for naming only even though it can detect other gases) So if 2 sensor's having the same ID are made they will overwrite each other in this list leaving one sensor orphaned in the world which cannot be referenced because it's value was overwritten by a new sensor having the same ID in this list. The Solution? Rather than having all atmos computer's look up sensor's from this 1 global list make each computer keep track of all sensor's it's responsible for in it's own local list[which i called `connected_sensor's`] this way 2 sensor's can have randomly generated names in the global `GLOB.objects_by_id_tag` list but the computer will know what sensor to look up in this list based on the stored sensor ID's in the `connected_sensor's` list Basically what i am getting at is now you can make as many air sensor's as you wish but you will know have to connect that sensor to the computer using a multitool. Notice in the video how i made 2 sensor's called `Supermatter Chamber Sensor's`] and every time you try to connect an sensor which has the same name[`Supermatter Chamber Sensor's` in this case] they will ovewrite the old sensor in it's list as shown in the video https://github.com/tgstation/tgstation/assets/110812394/b5283c3b-c8a1-4b94-a6a8-8ba7a0007615 **Why it's good for the game**  I agree. Also air sensor's taking up a full Tab/Section in the RPD UI wasted a lot of UI space so that's removed now. Also making the air sensor's wrenchable and pickable item's was also requested in https://github.com/tgstation/tgstation/pull/72019#issuecomment-1355499873 so you relate them to device's like meter's Another huge issue was that the number of air sensor's you can make in the world was limited because each sensor in the world must have a unique ID but that's finally fixed now so yeah make as many sensor's as you want. ## Changelog 🆑 add: air sensor's are craftable refactor: air sensor's can now be turned off by hand and can only be deconstructed by a welding tool refactor: removed `Params()` proc qol: unwrenched air sensors can be picked up & recycled like regular item's del: air sensor are removed from the RPD UI qol: air sensor's are no longer restricted by their unique ID's which mean you can craft as many air sensors as you want. /🆑 --------- Co-authored-by: Time-Green <timkoster1@hotmail.com> |
||
|
John WillardandGitHub
|
0c99bd28f4 |
Makes gasses use defines (#75542)
## About The Pull Request Adds defines for gasses and replaces uses I've found to instead use the defines. Can you believe I made this PR while trying to work with Xenos? This sucks! ## Why It's Good For The Game There's a lot of different uses of things like "o2" and "plasma", and they are pretty inconsistent. In some places, it's "hydrogen", in others it's "h2". In some it's "plasma", others "plasm". This unifies it all under defines so it has a less chance of breaking in the future. ## Changelog Nothing player-facing. |
||
|
AndrewandGitHub
|
4b01dbe5d4 |
Connect air alarm to air sensor (#75187)
## About The Pull Request To control vents and scrubbers in ordinance, burn and engine chambers, mappers extend the area outside of the walls towards a tile where they place the air alarm. With this PR, they can now assign `chamber_id` to an air alarm and connect to the chamber with an air sensor. There is a new map helper for this. Also, this connection can be done manually. You need to click on a sensor with a multi-tool, then unlock certain air alarm, and click with a multi-tool on it. This action will link sensor to an air alarm, reporting gas mixture from the sensor tile and giving control over the vents and scrubbers of the sensor's area. ### TLDR Before: <img width="718" alt="ordnance_before" src="https://user-images.githubusercontent.com/3625094/236577769-5d79871f-2dce-43be-a20a-e6669bfbc1c6.PNG"> After: <img width="638" alt="ordnance_after" src="https://user-images.githubusercontent.com/3625094/236577786-3c7e9c9f-1501-4747-bbe1-292fc4947b0d.PNG"> This is how the area is setup on meta station right now vs if it was setup with a link  This is also true for the supermatter chamber - you can make the air alarm display the gas mix in the actual chamber and avoid using mapping area hack there too. <img width="954" alt="supermatter_after" src="https://user-images.githubusercontent.com/3625094/236578528-4650b426-6bf0-4634-a5b0-cad7a50d5b01.PNG"> ## Why It's Good For The Game The area hack is no longer needed and you can place air alarm to control certain remote area wherever you want when you design a map. Even 3 air alarms next to each other controlling 3 different burn chambers. The air alarm will also report the gas mix on the actual tile of a sensor, instead of the gas mix before the air alarm, which is usually a normal habitable environment. Also, now you can build such chambers manually because there are no precise area editing tools available in-game to repeat the area hack. ## Changelog 🆑 add: Air alarms can be connected to an area remotely via air sensor with multi-tool and corresponding access qol: Mapping: Added air alarm helper to link air alarm with certain chamber_id on map load /🆑 |
||
|
|
5ba8cb295b |
Station monitoring console patches (#73096)
## About The Pull Request - Distro & Waste loop sensors were only displaying the values of the air on its turf not the actual pipes they were on, so the values were always constant. Thats fixed now. - Created a macro to map chamber id to air sensor to avoid typos. This also fixed being unable to connect to the waste loop sensor due to a typo in the word "_sensor". - When reconnecting to a different chamber other than distro & waste `atmos_chambers` is not lost when switching so you can once again connect back to distro & waste. After reconnecting make sure to again select the chamber from the drop down box cause the ui doesn't update automatically https://user-images.githubusercontent.com/110812394/215701505-105eba4d-d5d1-4a09-9ac7-0ab73fee2196.mp4 Fixes #73055 ## Changelog 🆑 fix: distro & waste sensors not reading values from the actual pipes they are on fix: losing distro & waste options from the drop-down box after connecting to a new sensor. refactor: all occurrences of _sensor with a macro to avoid typos. /🆑 --------- Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
|
5c46f65de4 |
Fixes atmos control not detecting Distro & Waste loop (#72287)
## About The Pull Request Fixes #72243 just had to append `"_sensor"` to its id cause atmos_control console uses that suffix a lot ## Changelog 🆑 fix: atmos control can detect distro & waste loop sensors /🆑 Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com> |
||
|
|
255d3b4098 |
Build your own atmos chambers (#72019)
## About The Pull Request https://user-images.githubusercontent.com/110812394/208232089-a183fb95-9326-4514-986a-a2b1e21be40c.mp4 **Notes** - You can print atmos control circuit boards at the circuit printer after research - You can only build one sensor for each gas type for in the whole map. This is because each sensor is assigned a unique chamber id from a fixed set of constants. Once all those values are used up there will be duplicates so yeah only sensor per gas type for that round - Un wrenching or destroying the injector/vent will automatically disconnect them from the sensor. I forgot to show that in the video - Destroying the sensor via right click with RPD will also automatically disconnect everything. It should be obvious but i made it even more obvious now ## Why It's Good For The Game From #71232  That and also i heard somewhere in the forum that this was highly requested ## Changelog 🆑 add: Gas sensors recipe to RPD code: linking all the stuff via multitool qol: make your own tank instead of moving around canisters /🆑 Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
MothblocksandGitHub
|
2e6b06353d |
Atmospheric machineries now interact with each other directly, rather than going through a radio layer -- saves about 0.4s of init time (#71232)
More than a decade ago, these were all coded to use a weird dynamic list radio broadcasting system to communicate with each other. If there was any depth that they were planning on creating with this, it didn't come to fruition, and it instead just wasted a lot of init time. Removing `post_signal` saves 198.41ms, fired 588 times from lots of different machinery. Its self cost was 81.44ms. `broadcast_status`, also removed, was taking 218ms. I'm pretty sure I'm done with this, but it's hard to tell given the nature of old radio signal code. A small self cost of 34.9ms was added in the form of /obj/Initialize checking id_tag to set in a global list. This could be optimized away by tagging everything that does use id_tag, but it's a loooot and I think this is just a useful mechanism to have. Not worth it IMO. The "Check Atmos Chamber Devices" verb has been removed. Everything it did *should* be replicated by runtimes on Initialize, which is both more obvious to mappers and shows up in unit tests since we spawn every ruin. |
||
|
|
4d6a8bc537 |
515 Compatibility (#71161)
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
|
||
|
MrMelbertandGitHub
|
92dc954ab5 |
Fixes 118(give or take) cases of mapload not being passed to initilaize (#69107)
fixes 114 cases of mapload not being passed to initilaize |
||
|
vincentiusvinandGitHub
|
ef036eb869 |
Assorted Ordnance Code+Map Quality Pass and QoL (#67097)
Three main things I do: Reinforce the remap that i have made with code changes, making the atmos control devices sane and easy to put if someone else stumbles upon this part of the code again. (a4aea1e - f16e620) Splits the ordnance areas and renames them, kills ordnance misc and things that have nothing to do with ordnance (anymore?) moves them to exp_lab (useful stuff here) and aux_lab (fluff stuff here like laser range in delta or second circuit lab in tram). (0c99f9f- 3c82a88) Adds a roundstart program disk containing nt frontier to the ordnance office table. Added a hint to file manager there too to help give players a nudge on how to publish papers. (fd747dc) First one: Makes mapping these things not require varedit, nicer for other people that dont know how the atmos control stuffs works. Second one: Misc lab has nothing to do with ordnance jesus christ. Also ord hallway is now irrelevant, our ordnance labs are very far from box now. Will probably make downstreams a bit angry for a while though since they might not be fully up to date on the ordnance maps. Third one: Pretty much justified it in the about section. Why is this not atomic: This touches all five maps and needs code backing, so I might as well combine them into one maintenance PR instead of giving my peers merge conflict three times. |
||
|
GhilkerandGitHub
|
ffd1ae5fc0 |
Rebalanced Power consumption, increase for machines (#66059)
Machinery power consumption rebalance. |
||
|
vincentiusvinandGitHub
|
204cbbb736 |
Ingame Atmos Reaction Guide (#65271)
About The Pull Request https://imgur.com/a/pMMEi4i https://imgur.com/a/xCrIcz4 Title, really. Adds an ingame guide to atmos. Currently hooked to the atmos monitors, analyzer, and the tablet app. Lots of reaction data not implemented yet, banking on the cleanup to get merged first, so drafting. Done, all reactions in. Haven't double checked them though. Code is pretty much finished, feel free to take a look. Ill probably retidy them while adding stuffs so no rush. Might add a reaction handbook obj later Implemented in analyzer. Dotted tooltip idea shamelessly stolen from preferences. Lots of the diffs are from breaking the sensor file up, dont worry about it. Why It's Good For The Game Less need to open the wiki in another page I guess. Changelog cl add: Added an ic atmos reaction guide. Available in your atmos control consoles/monitors, ntosatmos app, and analyzer. code: Some changes to how gas canister descriptions are generated. /cl |
||
|
vincentiusvinandGitHub
|
55336d1e53 |
Atmos Control Console Refactor (and syndiebase atmos tidyup) (#65372)
Main Takeaways For Mappers: Use monitored pathed atmos devices very carefully. Also dont put atmos_sensors willy nilly. They are used to hook to atmos control monitors. We want to keep at most one device broadcasting for each of the atmos sensor, inlets, and outlets. Run the mapping verb Check Atmos Chamber Devices to be sure, though this might not catch everything. Some of the warning are pretty harmless. For example if you have reconnected the "station atmos monitor" and you get no listener for distro/waste loop warning, it's safe to ignore. I don't know what the maptainer policy is on making new subtypes for offstation content, but if you do please branch off the general ones instead of the specific gas ones. If you aren't making a new subtype, varedit the general ones too. About The Pull Request: Need Would prefer this to be merged before #65271 (In game atmos guide). Not strictly necessary, just makes me sleep better knowing the handbook wont die alongside the rest of the UI. Fixes #36668 (Atmos Monitoring Consoles don't update it's sensors to the new tank after reconnect()) Fixes #32122 (Mix console fucked after reconnecting it) Also made the distro meter thing broadcast more info instead of just the pressure, because I'm sure nobody would care and it would make my life easier. A small high-level overview in case this breaks again in the future: A signal datum (not DCS) is sent by the atmospheric devices (injectors and vents) and will be received by the atmos computers. The data is then stored at the monitor object and then passed to the UI. This initial signal is sent by `broadcast_signal()`, called by `atmos_init()`. New sensors/vents (if you can actually get them in game, still only adminspawn/wrenchables afaik) will also initiate the conversation if atmos_init() is called, so it works fine. This means you need to unwrench and re-wrench the devices if you adminspawn them though, ugh. In case of a newly built computer, it needs to be the one that prompt the data to the devices, so we send a request signal. This is a bit inefficient since it doesnt work off of callbacks and assocs like DCS, but won't really matter since we're doing this rarely. We only talk with the injectors and vents when necessary here, while sensors and meters keep beeping with every process_atmos() tick so they rarely break. Why It's Good For The Game: Messy code gone (debatable). Refactored the atmos control console devices. The ones that hook to the big turf chambers. Distro meter now broadcast the whole gasmix info instead of just pressure to the monitors. Lavaland syndie's atmos chamber vents are now actually configurable. Moved a few things around to accomodate this. Lavalannd syndie chambers hooked to distro and moved distro pipe to layer2 atmos monitors can detect reactions now. Some minor code changes to how anomaly refinery and implosion compressor show the gas info. No changes expected, report if bug. recoded checks for atmos chamber abnormalities in debug verbs. |
