## About The Pull Request
A new pull request that DOESN'T make Lemon and Ghil kill me. _[I had
made a previous PR about the same original commits that was going to
make Volume Pumps leave a lot more gas in pipenets then people would
want.]_
Removed Hardcoded values from Volume_Pump.dm and moved them to __DEFINES
Updated documentation on Volume pumps because it was copied from
Pressure Pump. Volume pumps attempt to move a certain volume and ignore
pressure limits until exceeding them. This can lead to pressures well
above the limit, so there is no ‘perfecting’ of pressures, as previously
detailed by documentation.
Edited to be more specific.
## Why It's Good For The Game
Less Hardcoded values.
Documentation more readily reflects the realities of the game.
## Changelog
🆑
code: replaced hardcoded values in volume_pump.dm with __DEFINES vars
doc: Volume Pump's basic introduction was copied and pasted from the
Pressure Pump documentation, and made mention of trying to 'perfect the
pressure'. Volume pump doesn't care about pressure until it exceeds it,
so there is no 'perfecting' going on.
/🆑
---------
Co-authored-by: Riley Redd <riley@pcs-ms.com>
## About The Pull Request
Broken by 51f02b5acc I introduced logic
that would use SET_PLANE_EXPLICIT's context arg's PLANE (if it had no
turf) as a source.
Since we use SET_PLANE_IMPLICIT in atom Initialize, if we set a plane
before Init, it'll end up double offsetting. This was effecting gas.
Solution, because this case is so rare, is just to set the plane on init
and store the offset on the object until then.
## Why It's Good For The Game
Closes#75709Closes#73642
## Changelog
🆑
fix: Gas, like plasma, will now properly display on multiz stations
/🆑
## About The Pull Request
[Removes the pretense of relative multiz
levels](https://github.com/tgstation/tgstation/pull/76248/commits/0293fdc2bd8c8af7a0d18da33265e060789c71f7)
Our multiz system does not support having a z level that is only
connected one way, or which goes down backwards or anything like that.
That's a fiction of the trait system, the actual backend has never
really supported this.
This pr removes the assumptions we were making backend around this, and
uses that to save cpu time.
I am also converting multiz_levels from an assoc list to a pure one,
which saves significantly on access times and cleans up the code
somewhat.
Also I'm making the get_below/get_above procs into macros, for the sake
of cpu time.
[Converts the starlight disease to use BYOND's directional defines
instead of our
own](https://github.com/tgstation/tgstation/commit/7d698f02d991eb4e1bde56314c657cf6e48ceb5d)
To some extent spurred on by
https://github.com/DaedalusDock/daedalusdock/pull/298, tho it was known
before
## Why It's Good For The Game
Faster multiz code, faster init, etc etc etc
## About The Pull Request
Fix hypernoblium formation not accounting for the reduction factor when
sanity clamping the reaction rate.
Fix N2O formation not using updated consumption rates for sanity checks.
Fix BZ formation not accounting for nitrous oxide decomposition factor
for reaction rate sanity clamping.
## Why It's Good For The Game
So the reactions are more natural.
## Changelog
🆑
fix: Fix hypernoblium formation gas reaction rate sanity clamping not
accounting for the reduction factor.
fix: Fix N2O formation gas reaction rate clamping clamping for incorrect
consumption rates.
fix: Fix BZ formation reaction rate sanity clamping not accounting for
N2O decomposition factor.
/🆑
## About The Pull Request
Changes gas monitor gas reaction descriptions. They use the main gas as
the reference instead of the "reaction rate".
## Why It's Good For The Game
"Reaction rate" refers to the collective variables that are used as the
gas reaction rate in code, which is OOC in IC, which is fail RP.
Improves atmospherics RP standards by making them reference a physical
thing instead.
## Changelog
🆑
spellcheck: Improves gas monitor reaction information RP.
/🆑
## 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>
## About The Pull Request
Fire stacks status effect no longer uses a weakref for the mob light, I
am pretty sure there was no real reason to use a weakref there.
Deleted weird luminescent glow dummy, now it just uses the standard
moblight obj.
Put all /obj/effect/dummy/lighting_obj together in a single file and
added a comment explaining why they exist.
(I severely dislike the /obj/effect/dummy typepath, but I am very much
unsure if just replacing all of them with /obj/effect/abstract would
break shit)
## Why It's Good For The Game
Code organization good
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
/🆑
## About The Pull Request
[A common problem with explosions is an overabundance of
sleeping](https://github.com/tgstation/tgstation/commit/6499077a09469ff401c224c0510bc184c663b118)
In an attempt to solve this issue, let's not continue to sleep and do
work in door closing if the door is already deleted
(This is caused by firelocks activating due to other adjacent objects
deleting, triggering an atmos update, and closing the firelocks before
they get bombed. I don't have a elegant way of resolving that core
problem, so let's just minimize the impact)
[Nukes a stupid sleep loop in airlock
code](https://github.com/tgstation/tgstation/commit/5b16360520526d6f5aa3b511049456b74f33f430)
When an airlock was depowered, it would enter a sleep loop, decrementing
its delay by 1 second every well, one second, so long as it had the
right wires flipped
This is very stupid
Instead, let's use signals off wire changes and a combo of timer and
remaining time var to do this with JUST a timer
Most of the changes here are just swapping over wires to a setter to
make signal registration work\
## Why It's Good For The Game
Less sleeping around explosions means less dropped ticks after a bomb
goes off. Good just in general
Also this excises dumb boomer code and adds some hooks for other devs to
use (we should use wires more man)
## About The Pull Request
We should be blocking the primary ssair activity updates if the
subsystem hasn't started yet
## Why It's Good For The Game
https://github.com/tgstation/dev-cycles-initiative/issues/25
Total waste of time, wins maybe 0.2 seconds of init
## About The Pull Request
1. Fixes#66994
Round start turbines have their power net initialized but not player
constructed one's. Now the rotor will connect itself to the power net
once you close it with a screwdriver & disconnect itself when you open
it. Make sure there is a cable beneath the rotor for it to work
2. Fixes#72235
Turbine's can be built vertically if the rotor is parallel or in the
opposite direction with respect to its compressor & rotor. If any part
is missing or not aligned, you will get fully detailed balloon alert's
telling you exactly how you have wasted your life playing this game and
why it's too late to do anything about it
3. Fixes#36284
The total rpm is now rounded to an integer value cause it actually makes
sense and the gas moles during computation's are quantized(i.e. rounded
to zero if they become very small) so in near vacuum environment's you
won't get free power.
Also turbine now respects the value of `pump_gas_to()` proc which means
if this proc fails to move gas the work returned is 0 so hopefully this
should fix other gas related issues in the turbine as well
4. Turbine's don't start processing round start or during init as it
waste's a lot of processing power. They only begin processing when
turned on by computer & stop processing when turned off by the computer
5. The rotor component will now tightly monitor the state of its
compressor & turbine outlet during it's processing lifetime. This wasn't
the case previously because after you link all part's if the compressor
or rotor was destroyed/moved/whatever the rotor would still continue to
function as normal if it was already running.
Now if anything happens to these component's everything is reset & you
have to link them again so you don't get weird behaviour.
This was the old behaviour notice 3 wrong things
- the turbine is still rotating even after the compressor is deleted,
it's animation is still there
- the computer is showing the turbine is still working, only after i
turn it on & off does it show the error message
- the error message is all wrong it shows parts have their panel open
even though they are missing
https://github.com/tgstation/tgstation/assets/110812394/0a64e5a6-80ca-442b-bbac-2eabc5060777
This is the new behvaiour
- as soon as the compressor is deleted the turbine output also stops
working because the whole turbine was shutdown when it detected a
missing part(the turbine animation stops working)
- the computer immediately shows you an error message without switching
it on/off first. it also shows you the correct message telling you about
missing parts
https://github.com/tgstation/tgstation/assets/110812394/bf05224b-8fe4-41ca-a2e4-ca26b11fd3c7
6. Merged a lot of procs into big ones to improve readability & also
because it was unnecessary and early return's and a ton of sanity
check's to make sure everything fails gracefully if anything get's
deleted
**Imporant mathematical changes**
1. The not so important change `do_calculations()` is renamed to
`transfer_gases()` which does exactly what it says
2. The important changes `transfer_gases()` will now return the work
done(which can be +ve or -ve) ONLY IF `pump_gas_to()` succeds. i.e. only
if gas was successfully moved from one mixture to the other only then is
the work computed. This was done because logically makes sense.
All work is computed based on how much gas was moved i.e. the return
value of `pump_gas_to()`. So rather than computing the work done based
on how much gas is "Stored"[like how much gas is in the turbine] we
calculate work done based on How much gas was "Moved" from turbine to
the outside turf. i.e. all work calculated is relative
## Changelog
🆑
fix: finishing & closing the turbine core rotor part will now connect
itself to the cable beneath it allowing it to share its produced power
with everyone.
fix: turbine's now give detailed balloon alerts if you have a missing
component, or something is not aligned correctly during turbine
construction
fix: turbine's will not produce power in vaccume
fix: turbine's won't function if any of it's components are damaged or
misaligned after linking or during processing
/🆑
## About The Pull Request
This adds ghost orbit popups for the following:
- Macrobombs (or stacked microbombs) being triggered.
- HFR Meltdowns.
- Living players about to be gored by an emagged organ harvester.
- Nuclear devices being armed.
- Doomsday devices.
- Blob hosts bursting.
This also modifies the following ghost orbit popups:
- Toy hot potatoes will no longer cause a popup when armed.
- Normal spider eggs will not flash the byond window, only special egg
types.
## Why It's Good For The Game
Gives more gathering spots/information to deadchat. Let no entertaining
moment in this game go unobserved.
Spider eggs flashing your window for every single egg produced makes
alt-tabbing suck. I saw some guy on the forums complaining about it and
thought "huh yeah I guess he's got a point that pisses me off too" so
here we are.
## Changelog
🆑 Rhials
qol: Basic spider eggs no longer flash the byond window when ready to
hatch.
qol: Toy hot potatoes no longer give a ghost notification.
qol: Deadchat will be notified in the event of an imminent macrobomb
detonation, HFR meltdown, organ harvesting,
qol: Deadchat will be notified when a nuclear/doomsday device is
activated, as well as when a blob-infection bursts.
/🆑
## About The Pull Request
Line 101 in the gas_reactions file had a gas mislabeled.
## Why It's Good For The Game
Helps new Atmos techs when they are looking up gas reactions in the Tank
Monitor/Gas Supply Control Computer
## Changelog
🆑
spellcheck: changed gas to correct type in description
/🆑
## About The Pull Request
Fixes a small bug that slipped by a couple days ago that made
trillionth-of-a-mole gasses stick around in pipes and canisters. This
restores to behavior to what it was no more than a week ago, and gas
analyzers will still show 0 moles for a decent while before a gas is
fully removed.
## Why It's Good For The Game
Fixes#76034
get that plasma out of my air tank
## Changelog
🆑
fix: VERY small amounts of a gas (<0.0001 mol) in pipenets will once
again be fully removed
/🆑
**About The Pull Request**
There is no need to send gas name to the Gas Filter UI because
`getGasLabel()` already decodes the name from it's ID. So, let's save
some bandwidth.
## Changelog
🆑
refactor: don't send gas name to gas filter UI as the name is already
decoded there from it's ID
/🆑
Almost all of the logic used for gas mixtures does not work if they have
zero volume.
I don't want this to cause a breakdown in atmos so all I'm having it do
it throw a stack trace, but this should make it much easier in the
future to figure out where atmos problems are coming from.
I've also changed pipenet reconciliation to not use a zero volume gas
mixture, and instead only create the gas mixture after calculating what
the volume should be
## About The Pull Request
Meters can have a null target if the pipe below them is destroyed or
removed; or if mappers fuck up.
## Why It's Good For The Game
Prevents runtimes
## Changelog
I didn't realize that an edge case could keep the alarms from reseting
their warning message.
The issue happened when a warning message was stored, like a low
temperature one, a second air alarm issue *without* a warning message
was triggered, like Plasma, and then the first issue was fixed.
Alarms kept repeating the first warning message as long as the second
issue was up.
This fixes that, alarms will reset their message individually, ignoring
other issues the alarm is triggering.
## About The Pull Request
https://github.com/tgstation/tgstation/assets/66052067/fa4450d0-f5b1-40e4-b283-57da6eba316c
Adds a button next to the relabel button in the UI that lets players
recolor canisters themselves. The relabel button overrides this, but
it's easy enough to re-color something if you really want it to stay
that way.
## Why It's Good For The Game
I realized earlier today that while we have the GAGS system for the
canisters, we never really fully utilized it, and I thought how it would
be helpful for players if they could more visually organize their
canisters.
I.e. Giving your "hot oxygen" canister a red ring, cold tritium a blue
ring, etc.
## Changelog
🆑 Wallem
qol: Adds a button that lets you recolor air canisters to enable easier
organization.
/🆑
A long long time ago, when I was but a wee coder, I made the Scrubber
Clog event. I wasn't great at coding then, but about a year later I have
returned to finish what I started.
This PR contains a full code/balance/feature update for the event,
bringing it up to what fledgeling coder Rhials had envisioned but wasn't
experienced enough to do. This contains no fundamental or conceptual
changes, just some TLC.
Since everything's in a new file and there isn't a diff to compare
things with, I'll try to give a quick summary of everything:
FEATURES:
- _The clog event now uses the ventilation pumps instead of scrubbers.
It is now the ventilation clog event. Rejoice._
- Clogs now make a filthy mess when they occur, and make noise when
spawning mobs.
- As more mobs spawn, even more of a mess is made. Different clog event
intensities will produce different messes.
- The mob roster has been updated to include the Mobroach, Mothroach,
and Viscerator for the Strange clog event, and the Hauberroach for the
Major clog event.
CODE:
- The event is now fully self-contained, without requiring any code on
the vent itself to work.
- plunger_act() now has its own signal.
BALANCE (This is just a bunch of tiny insignificant number tweaking
don't worry):
- More mobs can be spawned at once by the event. This shouldn't have any
real impact on how dangerous the minor/major clog events are, but might
make the critical/strange events a smidge more dangerous.
- Max occurrences have been increased. The minor/major clog events are
no longer limited to only three per round.
- There is now a slight chance that a clog event will not announce
itself.
## About The Pull Request
While trying to turn the base system into a separete proc I thought I
had commited this fix in, but did not...
Also removed a redundant check_danger() I left in while fixing merge
conflicts because I'm good at gitfu.
And thanks for Zxaber for letting me know about this issue as soon as
possible.
## Why It's Good For The Game
Air alarms talking forever do be bad...
## Changelog
🆑 Guillaume Prata
fix: Air Alarms will properly shut up when atmos is fixed.
/🆑
## About The Pull Request
This PR makes air alarms state atmos issues they are dealing with.
Simple Low/high pressure/temperature messages will be said every 10
seconds if there is something going on with the air alarms.
Similar to how vending machines do slogans for their products.
I didn't add any check for particular gases because it looked
unnecessary, but it is trivial to add more into the system.
It now has a speaker wire, so a way to disable audible spam while
letting the air alarm detect issues if you need this for an atmos
project.
## Why It's Good For The Game
Base message as example, it changes into "Danger! Low pressure
detected." and similar.
This lets players know what the issue is on a room easier, specially
helpful for new players that might not understand atmos enough.
The only other option to getting this information is atmos equipment
like the ranged gas analyzer, being a Silicon to check the air alarms
from range or walking to the air alarm, which new or ill equipped won't
do.
Something, something, atmospherics is an eldritch beast with a big
barrier of entry on not only playing the job, but just understanding the
basic system, hopefully this cuts one tail of this mysterious creature.
And I just think talking machinery is cute!
## Changelog
🆑 Guillaume Prata
add: Air alarms will now talk about their atmospheric problems (low/high
pressure/temperature) so players can understand what is the room's issue
easier.
/🆑
---------
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
## 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.
## 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
/🆑
## About The Pull Request
Resprites stock parts to bring them up to date, changes manipulators to
servo motors as I couldn't make manipulators work well at this scale.
(Power cells sold separately)
## Why It's Good For The Game
The old stock parts are dated, in some cased quite ugly, and in the case
of manipulators a ball of assorted pixels. Incidentally removed a couple
of single letter var names.
## Changelog
🆑
image: Stock parts have been resprited.
code: Manipulators have been renamed to servo motors, all related types
have been repathed to match.
/🆑
Ladies, Gentlemen, Gamers. You're probably wondering why I've called you
all here (through the automatic reviewer request system). So, mineral
balance! Mineral balance is less a balance and more of a nervous white
dude juggling spinning plates on a high-wire on his first day. The fact
it hasn't failed after going on this long is a miracle in and of itself.
This PR does not change mineral balance. What this does is moves over
every individual cost, both in crafting recipes attached to an object
over to a define based system. We have 3 defines:
`sheet_material_amount=2000` . Stock standard mineral sheet. This being
our central mineral unit, this is used for all costs 2000+.
`half_sheet_material_amount=1000` . Same as above, but using iron rods
as our inbetween for costs of 1000-1999.
`small_material_amount=100` . This hits 1-999. This covers... a
startlingly large amount of the codebase. It's feast or famine out here
in terms of mineral costs as a result, items are either sheets upon
sheets, or some fraction of small mats.
Shout out to riot darts for being the worst material cost in the game. I
will not elaborate.
Regardless, this has no functional change, but it sets the groundwork
for making future changes to material costs much, MUCH easier, and moves
over to a single, standardized set of units to help enforce coding
standards on new items, and will bring up lots of uncomfortable balance
questions down the line.
For now though, this serves as some rough boundaries on how items costs
are related, and will make adjusting these values easier going forward.
Except for foam darts.
I did round up foam darts.
Adjusting mineral balance on the macro scale will be as simple as
changing the aforementioned mineral defines, where the alternative is a
rats nest of magic number defines. ~~No seriously, 11.25 iron for a foam
dart are you kidding me what is the POINT WHY NOT JUST MAKE IT 11~~
Items individual numbers have not been adjusted yet, but we can
standardize how the conversation can be held and actually GET SOMEWHERE
on material balance as opposed to throwing our hands up or ignoring it
for another 10 years.
Firealarms & Airalarms `deconstruct()` procs are wrong, they spew out
electronics & cable regardless of what build stage their on
Fire alarms providing free electronics & cable without even installing
them
https://user-images.githubusercontent.com/110812394/233784785-650fbd64-3c6c-44c8-b377-c3a8244d28ac.mp4
Air alarms providing free electronics & cable without even installing
them
https://user-images.githubusercontent.com/110812394/233784799-cdd38967-8a59-454d-8da4-1360d03ff12c.mp4
Bug exploits now come to an end
Also fixes balloon alerts run timing when cutting terminals connected to
apc's/smes etc. because the atom gets deleted, by the time the balloon
alert gets executed it adds a timer on the deleted object causing
runtimes.
## Changelog
🆑
fix: air alarms correctly spew out cable & electronics depending on
their build stage when their integrity reaches 0 i.e. destroyed
fix: fire alarms correctly spew out cable & electronics depending on
their build stage when their integrity reaches 0 i.e. destroyed
fix: balloon alerts runtiming when cutting terminals
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
1. `pre_attack()` was defined twice, removed one
2. `attackby()` does the exact same thing as `pre_attack()` for
installing upgrades so removed that
3. Fixes runtime
When you attempt to unwrench a pipe via the RPD but you interrupt the
`do_after()` proc by moving. it doesn't need to crash but simply return
if unwrenching was unsuccessful see
`/obj/machinery/atmospherics/wrench_act()`
## Changelog
🆑
refactor: removed duplicate `pre_attack()` & redundant `attackby()`
procs which did the same thing
fix: unnecessary crash when unwrenching pipes/devices with the RPD
/🆑
## About The Pull Request
We assumed 0 meant no emissive blocker, but moth changed that a while
back, so post /atom/movable/Initialize generic emissive blockers just..
didn't work
Let's uh, fix that
Oh also makes pipes update their icon BEFORE they call update_icon
parent, so their emissive blockers look right
## Why It's Good For The Game
Closes#74905
## Changelog
🆑
fix: Things that block glow will now like, do that again
/🆑
## About The Pull Request
I really don't want to talk about it... fixes#74748
Bunch of old atmos UIs doing weird things that were unclear at the time
of refactoring
Crystallizer was looking up labels and colors by gas name vs id
HFR, I'm still not happy with this, but this is the original
implementation
```
icon={data[input_switch] ? 'power-off' : 'times'}
content={data[input_switch] ? 'On' : 'Off'}
selected={data[input_switch]}
```
## Why It's Good For The Game
Bug fixes
## Changelog
🆑
fix: HFR should now allow you to select input/moderator rates
fix: Crystallizer ui should now properly show input gases
/🆑
Co-authored-by: Jeremiah <jlsnow301@pm.me>
## About The Pull Request
Read Title
Start your VS code in debug mode, insert a cell inside the electrolyser
and toggle it on/off via the UI(not alt click). you will get this error
## Changelog
🆑
fix: null client error for balloon alert when toggling the electrolyser
on/off via the UI
/🆑
## About The Pull Request
GBP NO UPDATE SINCE ITS MY OWN BUG
I assumed you could unwrench devices, turns out they have multiple gas
mixtures
Tested all atmos devices in game, you can unwrench them instantly if
they have 0 moles in all nodes
## Why It's Good For The Game
Was supposed to be like this in
https://github.com/tgstation/tgstation/pull/74617
## Changelog
🆑
fix: You can instantly unwrench empty atmos devices now
/🆑
This tracks the seconds per tick of a subsystem, however note that it is
not completely accurate, as subsystems can be delayed, however it's
useful to have this number as a multiplier or ratio, so that if in
future someone changes the subsystem wait time code correctly adjusts
how fast it applies effects
regexes used
git grep --files-with-matches --name-only 'DT_PROB' | xargs -l sed -i
's/DT_PROB/SPT_PROB/g'
git grep --files-with-matches --name-only 'delta_time' | xargs -l sed -i
's/delta_time/seconds_per_tick/g'
## About The Pull Request
Unwrenching empty atmos pipes/devices is now instant
## Why It's Good For The Game
Worst part about playing atmos is how long it takes to set up builds,
especially if you want to unwrench all the ports and pipes that come
after the main yellow Pure loop. Also annoying if you misclick and have
to spend time unwrenching an empty pipe
Just QOL for atmos players
## Changelog
🆑
qol: Unwrenching empty atmos pipes/devices is now INSTANT
/🆑
## About The Pull Request
Fixes#74431
1. Adds examines for alt click & ctrl click
2. Alt click cycles between min, median & max temperature ranges now
3. removed useless init code in pipes.dm
## Changelog
🆑
fix: thermo machines can be ctrl dragged again
qol: alt click cycles between min, median & max temperature ranges
refactor: removed useless init code
/🆑
---------
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
Co-authored-by: Jacquerel <hnevard@gmail.com>
## About The Pull Request
Added screentips and balloon alerts to many atmos machines/pipes
Volume pump overclocking overlay is much slower and less seizure
inducing
RPD screentips for right clicking pipes to copy settings
Removed (RPD) from the RPD's name since having an abbreviation in the
name is ugly
Crystallizer and electrolyzer use ctrl+click and alt-click to turn on
On examine electrolyzer tells you about anchoring to drain from APC
instead of cell
## Why It's Good For The Game
QOL for atmos stuff, user friendliness and better experience
## Changelog
🆑
fix: Volume pump overclocking animation is much slower, no more
headaches
qol: Added screentips to the RPD; screentips and balloon alerts to many
atmos machines and devices
🆑
# MAINTAINER - USE THE BUTTON THAT SAYS "MERGE MASTER" THEN SET THE PR
TO AUTO-MERGE! IT'S MUCH EASIER FOR ME TO FIX THINGS BEFORE THEY SKEW
RATHER THAN AFTER THE FACT.
## About The Pull Request
Hey there,
This took a while to do, but here's the gist:
Python file now regexes every file in `/code` except for those that have
some valid reason to be tacking on more global defines. Some of those
reasons are simply just that I don't have the time right now (doing what
you see in this PR took a few hours) to refactor and parse what should
belong and what should be thrown out. For the time being though, this PR
will at least _halt_ people making the mistake of not `#undef`ing any
files they `#define` "locally", or within the scope of a file.
Most people forget to do this and this leads to a lot of mess later on
due to how many variables can be unmanaged on the global level. I've
made this mistake, you've made this mistake, it's a common thing. Let's
automatically check for it so it can be fixed no-stress.
Scenarios this PR corrects:
* Forgetting to undef a define but undeffing others.
* Not undeffing any defines in your file.
* Earmarking a define as a "file local" define, but not defining it.
* Having a define be a "file local" define, but having it be used
elsewhere.
* Having a "local" define not even be in the file that it only shows up
in.
* Having a completely unused define*
(* I kept some of these because they seemed important... Others were
junked.)
## Why It's Good For The Game
If you wanna use it across multiple files, no reason to not make it a
global define (maybe there's a few reasons but let's assume that this is
the 95% case).
Let me know if you don't like how I re-arranged some of the defines and
how you'd rather see it be implemented, and I'd be happy to do that.
This was mostly just "eh does it need it or not" sorta stuff.
I used a pretty cool way to detect if we should use the standardized
GitHub "error" output, you can see the results of that here
https://github.com/san7890/bruhstation/actions/runs/4549766579/jobs/8022186846#step:7:792
## Changelog
Nothing that really concerns players.
(I fixed up all this stuff using vscode, no regexes beyond what you see
in the python script. sorry downstreams)
## About The Pull Request
It is faster to operate on a gas list, especially if cached, then it is
to operate on a datum.
Doing this cause I'm seeing cost in merge() post #74230
Hits on a few other important places too. self_breakdown and such. Worth
it IMO
Could in theory go further by caching the global list. I'm tempted I
admit but it needs profiling first and it's late
EDIT: I have not slept, and have gone tooo far
[Micros /gas_mixture/copy and copy_from, adds a new proc to handle
copying with a ratio,
copy_from_ratio](https://github.com/tgstation/tgstation/pull/74233/commits/91da0003daa9485962525d3e6bc9170a4c09876b)
[91da000](https://github.com/tgstation/tgstation/pull/74233/commits/91da0003daa9485962525d3e6bc9170a4c09876b)
The ADD_GAS sidestep saves us 0.1 seconds of init (used to at least.
Ensuring we don't break archive is gonna have a cost. I don't want to
profile this so I'll estimate maybe 0.05 seconds). The faster version of
copy_from is just well, better, and helps to avoid stupid
[Optimizes pipeline
processing](https://github.com/tgstation/tgstation/pull/74233/commits/bf5a2d2d60554da2ce5fa1ac5f6c4179f6208cb2)
[bf5a2d2](https://github.com/tgstation/tgstation/pull/74233/commits/bf5a2d2d60554da2ce5fa1ac5f6c4179f6208cb2)
I haven't slept in 36 hours. Have some atmos optimizations
Pipelines now keep track of components that require custom
reconciliation as a seperate list.
This avoids the overhead of filtering all connected atmos machinery.
Rather then relying on |= to avoid duplicate gas_mixtures, we instead
use a cycle var stored on the mix itself, which is compared with a
static unique id from reconcile_air()
This fully prevents double processing of gas, and should (hopefully)
prevent stupid dupe issues in future
Rather then summing volume on the gas mixture itself, we sum it in a
local var.
This avoids datum var accesses, and saves a slight bit of time
Instead of running THERMAL_ENERGY() (and thus heat_capacity(), which
iterates all gases in the mix AGAIN) when processing gas, we instead
just hook into the existing heat capacity calculation done inside the
giver gases loop
This saves a significant amount of time, somewhere around 30% of the
proc, I think?
This doesn't tackle the big headache here, which is the copy_from loop
at the base of the proc.
I think the solution is to convert pipelines to a sort of polling model.
Atmos components don't "own" their mix, they instead have to request a
copy of it from the pipeline datum.
This would work based off a mutually agreed upon volume amount for that
component in that process cycle.
We'd use an archived system to figure out what gases to give to
components, while removing from the real MOLES list.
We could then push gas consumption requests to the pipeline, which would
handle them, alongside volume changes, on the next process.
Not sure how I'd handle connected pipelines... Merging post reconcile
maybe?
This is a problem for tomorrow though, I need to go to bed.
Saves about 30% of pipeline costs.
Profiles taken on kilo, until each reconcile_air hits 5000 calls
[old.txt](https://github.com/tgstation/tgstation/files/11075118/Profile.results.total.time.txt)
[new.txt](https://github.com/tgstation/tgstation/files/11075133/profiler.txt)
## About The Pull Request
This is a continuation of
https://github.com/tgstation/tgstation/pull/74085 - I announced in the
comments there that this would be my next PR, and this is it.
Removes SSnetwork, ``/datum/ntnet``,
``/datum/component/ntnet_interface``, ``var/network_root_id``, the
network unit test, and a lot of other things related to networks.
- NTNet circuits now check for an Ntnet relay, and uses signals to
operate.
- Logs in Wirecarp is now only for PDA and Ntnet Relay things, so you
can no longer see what ruins exist using it (why should Wirecarp know
that Oldstation spawned? The flavor is that they dont know its there).
- Removed it from MULEbots entirely, I don't think it even did anything
for them? Botkeeper seems to work without it, so it's possibly there
from pre-tgui PDAs.
- Moves assigning random names to a base proc instead of being tied to
network, this is things like random-naming scrubbers/vents. The behavior
hasn't changed at all.
- Makes Ntos work for consoles when relays are down, as the comments
said they're supposed to (because they're wired). I think this was an
accidental change on my part, so this is a revert of that.
## Why It's Good For The Game
Ntnet is ancient code that hasn't given us much that we can't do with
already existing alternatives, we've been slowly moving away from it for
init times, and though a large portion of that was limited to airlocks,
I still don't think this is a system worth keeping around.
It's way too complex to expect feature coders to do anything with it,
and too old with better alternatives for anyone to want to improve any
of it.
## Changelog
🆑
fix: Computers are now properly connected to Ethernet, and can use Ntos
when Relays are down.
refactor: Removes Ntnet and Ntnet interfaces, which was only used by
Ntnet circuits (which now directly checks for a Relay to work) and
MULEbots, which did nothing with it.
balance: Wirecarp no longer tells you what ruins spawned in a round,
instead it's limited to PDA logs, and tells you the source too. This
means the RD can catch someone running illegal programs if they don't
make any attempt at hiding it.
qol: Wirecarp logs is now set to save 300 at once, instead of 100 and
being increased to 300 by the RD during the round. This is pretty
insignificant, since there's no reason to NOT want as many logs as
possible.
/🆑
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
## About The Pull Request
Volume pump lights flash if overclocked
examine text says you can multitool them
multitools have screentips for volume pumps
## Why It's Good For The Game
Literally impossible to know about this feature unless an atmos tech pro
shows you ingame or you codedive
## Changelog
🆑
qol: It is now obvious when examining volume pumps that you can
multitool them to overclock them to disable pressure limits and spill
gas out. Overclocked volume pumps flash lights
/🆑
---------
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
## About The Pull Request
These changes fix how machines are pried open with crowbars. Currently,
most machines can be pried open, but many of them have no method for
being closed again. This means they can be pried once, and then never
again (as their internal logic has them stuck in an "open" state).
Additionally, the densities of these machines is also inconsistent, as
density is tied to the procs for opening/closing machines (open =
non-dense, closed = dense). Thus, these new changes allow desired
densities to be passed to `open_machine()` and `close_machine()`, as
well as `default_pry_open()`, meaning that atypical machine densities
can be maintained (e.g. machines that should remain dense when open, or
non-dense when closed).
I've also added a `close_after_pry` boolean parameter to the
`default_pry_open()` proc, which determines whether to immediately close
a machine after opening it. This is useful for machines that don't
really have a use case for remaining open, often lacking a sprite to
represent this state as well.
* Note: Opening and immediately closing machines with this boolean will
still drop their contents onto the floor, but will now immediately
"close" in their logic, allowing for further prying attempts in the
future.
It's worth noting that this implements default density values for these
procs, which match the existing behavior for machines, so as to
(hopefully) not disrupt existing or expected machine behavior.
Two caveats to these changes currently exist:
1. On machines that immediately close after prying, the prying action
can now be spammed to the chat with repeated clicking. I'm uncertain if
this needs some sort of spam protection or if it's fine as is.
2. I've only been able to manually test this code. I'd love to write
unit tests for it, as it affects a lot of different machines, but don't
know where to begin with DM Unit Testing (or which files would be good
examples to reference in the code base).
* Note: I did manually test each and every machine that calls
`default_pry_open()` and they all seem to be working correctly. (Except
for `obj/machinery/plumbing/sender`, but that doesn't seem to need
prying, as it has no contents to drop, only reagents.)
As always, let me know if any improvements/changes should be made.
This closes#26833.
## Why It's Good For The Game
These changes allow crowbar prying to correctly occur multiple times on
any machine, which is intended behavior. It prevents player confusion
that could occur when a machine couldn't be pried open a second time
during a shift, even though it had previously been pried before, forcing
players to question themselves. (Are they missing something? Did they
perform the action a different way last time? Is the machine actually
still powered on instead of off? Etc.)
These changes also maintain the correct density for machines after
prying, preventing scenarios where a machine might behave differently
once it had been pried open. (An example of this was being able to walk
through a smartfridge after prying it open.) Additionally, players are
no longer required to know/use workarounds (such as machine disassembly)
to retrieve a powered-off machine's contents.
Overall, these changes improve consistency around machines, creating
more scenarios where they behave as players would expect.
## Changelog
🆑
fix: machines can now be pried open more than once.
fix: machines now have the correct density when pried open.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
On the tin, doing it like this means we can reduce our overall line
fingerprint whenever we have to add two or more traits from the same
source on the same target. Especially helps when we get to the 4+ range
of traits, a breath of fresh air even.
Doesn't mean we have to do for loops, as that's already handled within
the define as well. I replaced some of the checks with `length()`
checks, let me know if I should switch it over to something else (maybe
`islist()`)? We stack_trace whenever we're not passed a list reference
on purpose, and sometimes var/lists are null by default (or just empty,
making this redundant).
## Why It's Good For The Game
I commonly feel the urge to write "use `AddTraits()`" or something in
reviews, then am sad when I remember it doesn't exist. I will no longer
be sad.
Can ensure a lot more trait safety as well by using static lists- when
both ADD_TRAIT_LIST and REMOVE_TRAIT_LIST re-use the same list, you are
confident (from a static point of view) that everything that you want to
be adding/removing works.
I may have missed a few things where this could be used, but both macros
implemented in this PR still use the same framework that was being used
in the last four years- so stuff won't break if left untouched. Just a
nifty new tool for developers.
also fixed up some code in the area, numerous bugs were found and
exploded
## About The Pull Request
I should have caught this in #73850 my bad.
When areas get merged the vents & scrubbers of the target area don't get
correctly unassigned from the old area and instead gets assigned twice
to that new area causing them to appear twice in the air alarm
interface.
Also merged `Initialize()` and `New()` into just `Initialize()` cause
like why did they split it into two procs?
## Changelog
🆑
fix: vents & scrubbers getting assigned twice to an area when it's
merged with another area via station blueprints
refactor: merged` Initialize()` & `New()` of vents & scrubbers into just
`Initialize()`
/🆑
EliteCreature
