* [MDB IGNORE] dir sanity, primarily on WALLITEMs (#62601)
About The Pull Request
Wall items mostly use the direction from the floor to the wall in the named mapping helper. Wall items mostly use the direction from the wall to the floor for the internal dir variable.
This leads to a headache when it comes to working out what conflicts with what, and what needs placing where.
Wall frames provided a member, inverse, which specified whether or not to invert the direction of the item when looking for conflicts. It was also used to specify whether to look for conflicts outside of the wall (cameras and lights appear external to the wall) or inside the wall (most wall items). This flag was set for Intercoms, APCs, and Lights. Since APCs and Lights expect a floor-to-wall direction, and Intercoms expect a wall-to-floor direction, this means that APCs and Lights were getting the correct direction, and Intercoms were getting the wrong direction.
Some implications of this setup were:
You could build an APC on top of another wall item, provided there was nothing external attached to the wall and the area didn't have an APC.
You could stack Intercoms indefinitely on top of the same wall, provided you weren't in a one-tile wide corridor with something on the opposite wall.
Or both! Here's twenty Intercoms placed on the wall, and a freshly placed APC frame after placing all Intercoms and deconstructing the old APC:
endless-stack-of-intercoms
Not everything used this inverse variable to adjust to the correct direction. For example, /obj/machinery/defibrillator_mount just used a negative pixel_offset to be visually placed in the correct direction, even though the internal direction was wrong, and never set! This also let you stack an indefinite number of defib mounts on the same wall, provided it wasn't a northern wall... except you could do this to northern walls too, since defibs weren't considered a wall item for the purposes of checking collisions at all!
Ultimately, every constructable interior wall item either used this inverse variable to adjust to the correct placement, set a negative pixel_offset variable to have its offset adjusted to the correct placement, or overrode New or Initialize to run its own checks and assignment to pixel_x and pixel_y!
Inventory: Table of various paths, related paths, and the adjustments they used
Unfortunately, untangling /obj/structure/sign is going to be another major headache, and this has already exploded in scope enough already, so we can't get rid of the get_turf_pixel call just yet. This also doesn't fix problems with the special 2x1 /obj/structure/sign/barsign.
Some non-wall items have been made to use the new MAPPING_DIRECTIONAL_HELPERS as part of the directional cleanup.
tl;dr: All wall mounted items and some directional objects now use the same direction that they were labelled as. More consistent directional types everywhere.
Why It's Good For The Game
fml
Changelog
cl
refactor: Wall mounted and directional objects have undergone major internal simplification. Please report anything unusual!
fix: You can no longer stack an indefinite amount of Intercoms on the same wall.
fix: Defibrillator Mounts, Bluespace Gas Vendors, Turret Controlers, and Ticket Machines are now considered wall items.
fix: Wall mounted items on top of the wall now consistently check against other items on top of the wall, and items coming out of the wall now consistently check against other items coming out of the wall.
fix: The various directional pixel offsets within an APC, Fire Extinguisher Cabinet, Intercom, or Newscaster have been made consistent with each other.
fix: The pixel offsets of Intercoms, Fire Alarms, Fire Extinguisher Cabinets, Flashers, and Newscasters have been made consistent between roundstart and constructed instances.
fix: Constructed Turret Controls will no longer oddly overhang the wall they were placed on.
qol: Defibrillator mounts now better indicate which side of the wall they are on.
fix: Some instances where there were multiple identical lights on the same tile have been fixed to only have one.
/cl
* [MDB IGNORE] dir sanity, primarily on WALLITEMs
* apc directionals
* bluespace vendor fix
* defib fix
Co-authored-by: esainane <esainane+github@gmail.com>
Co-authored-by: jjpark-kb <55967837+jjpark-kb@users.noreply.github.com>
* Adds a hard limt to hfr fuel datums, moves antinob down to match it (#62418)
* Adds a hard limt to hfr fuel datums, moves antinob down to match it
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Modernizing Radiation -- TL;DR: Radiation is now a status effect healed by tox healing, and contamination is removed
* Fixing conflicts
* Makes it compile, yeet all the RAD armor from everywhere (thanks RegEx!)
* Removing more lingering rad armor (woo)
* Damnit powerarmors
* Bye bye rad collectors!
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Pressure Tank: Fix many runtimes, consistency (#62317)
Use MINERAL_MATERIAL_AMOUNT, add and use TANK_PLATING_SHEETS in place of magic numbers everywhere.
If you get a spooky warning about the tank being pressurized as you slice it open with a welding tool, you actually get consequences. These consequences (and the new conditions for it) are consistent with the checks in atmosmachinery.dm.
Don't try to use an array index of 2 on the custom_materials associative list which is meant to hold a single entry. If custom_materials ends up with multiple materials somehow, produce a frame with nothing rather than a plated frame.
Properly pass the amount of a material to create when dropping.
Don't try to use a stackable item which doesn't have a material_type.
* Pressure Tank: Fix many runtimes, consistency
Co-authored-by: esainane <esainane+github@gmail.com>
* Ok. Let's talk yeah? (#62415)
This pr changes the temperature limit on nitryl. Lowers it from 600k to roughly 340
So I assume you're familiar with singletank/cap bombs (Fuck you assembly people)
Idea is basically the same as a ttv, except it's not a ttv, so you've got no control
It's a product of a cursed problem around explosion code that I'm willing to harbor
We want two things. TTVs that work off pressure, in a semi realistic way, and tanks that explode when you fuck up your ttv
Only makes sense that the tanks should have at least the same base logic as the ttv right? That's kind of the issue
I'm not willing to compramise on any of those three points, so things are the way they are
Ok now that we're all on the same page. You remember that bit I said about no control?
Nitryl has a decomposition reaction. Exists so you can't plumb the station with the stuff, etc etc
Takes nitryl, which is "canonically" 1 nitrogen 2 oxygen, decomposes it into 02, and heat
Agressively soulful reaction right? Really slow, so it's not an instant thing, but it does go through
Anyway. So let's say we take a ttv mix, trit + plasma, and take advantage of some parts of that reaction.
1: It takes a small amount of o2 and a large amount of no2, and returns you a large amount of o2 over a long period of time
2: It's exothermic. So we're slowly ramping up the temperature of our mix. Very very slowly mind
I'm sure you can figure out the problem here. Giving people what amounts to fuses, which at this scale is a problem
It honestly does kind of hurt to try and remove this, because frankly if I played this game I'd be telling people about it whenever I got the chance (Consider what I just did "that")
Thing is it allows for levels of nuke that are not workable. It's a concept I've been aware of for a while, but I A: didn't realize how stronk it was, and B: didn't think it was well known enough
People are using it a lot, and god it's stronk
Please consider this a by-proxy salt pr, since again, I don't play
Oh and to be clear, I won't do prs like this anytime someone uses something strong. That's why servers have admins. I've got sanity limits though, and this crossed those
* (Tries) to remove long timer singlecaps
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* removes double spaces before symbols (#62397)
This can apparently cause some bugs on occasions, so I thought I might as well try to kill them all.
* removes double spaces before symbols
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* HFR frontend rework (#61737)
This makes the interface much more usable, and tries to help introduce the concepts involved in a very complicated system. The current interface is a bit clunky to use, and does not offer much guidance as to what actions are possible, or what the implications of taking them might be. You can't see the readouts at the same time you're tweaking the controls. Many failure states are not warned about, or even made clear when they're actively happening. To this end, this PR provides many very helpful qol changes, listed in the changelog below.
* HFR frontend rework
Co-authored-by: esainane <esainane+github@gmail.com>
* runtime fix for borgs cryoing with upgrade modules + no more mmi laying around after they cryo, and various other runtime fixes
* Fixing conflicts
Co-authored-by: Seris02 <49109742+Seris02@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* HFR ambience: Quieten when out of fuel (#61956)
HFR ambience will no longer play intensely when the HFR is out of fuel.
This has always been a problem, but more cues for the HFR being out of fuel are helpful.
* HFR ambience: Quieten when out of fuel
Co-authored-by: esainane <esainane+github@gmail.com>
* Rename freon_gas_act to freeze_turf (#61958)
This was only used from two places, neither of which involved freon.
* Rename freon_gas_act to freeze_turf
Co-authored-by: esainane <esainane+github@gmail.com>
* HFR backend rework (#61593)
* HFR: Remove some unused defines
These are unused, and dangerously misleading.
* HFR: Purge damage/heal magic numbers using MATH
Everything is now defined in terms of human readable constants.
No mechanical changes.
Things that technically changed:
- The overfull function was technically a very fine grained step
function due to the rounding function, so technically you only jumped
0.0125 points of damage per tick per every whole mole of mass above.
We now use a smooth function, because oh my god why bother
Things that might look like they were changed:
- Subcritical healing. Healing only happened if the fusion mass was
under 1200 anyway, so there's no point in using a higher threshold.
Things that probably should be later changed:
- Alternate || conditions when nothing happens if the first condition
isn't met
- HYPERTORUS_MAX_MOLE_DAMAGE was used as a minimum, this probably wasn't
intentional
* HFR: Split up and time main processes
Also make COLD_COOLANT parameters even more tunable and readable with
the incredible power of MATH
These constants should ideally be computed once, rather than be an
inlined #define, but it doesn't matter much. Alternatively, the
constants could be vareditable vars, and have an update proc to make
balance testing easier.
* HFR: Merge positive and negative modifiers
positive_modifiers already added included a negative modifier at the end
anyway, and keeping track of antinoblium both adding 10 to positive
energy and removing 10 from negative energy was a slight headache.
They're only ever immediately summed, anyway.
* Completely refactor HFR main processes
stone cold fuck it this needed to happen sooner rather than later anyway
Highlights:
- The !selected_fuel early return in fusion_process() was redundant,
check_fuel() immediately checks selected_fuel anyawy.
- The check_fuel() at the start of moderator processing would never fail,
as fusion_process() made an early return with check_fuel().
This was indenting the giant moderator effect block for nothing
- The if (power_output) wrap does nothing in practice, since it checks
for a value that's clamped between 1 and 100 then multiplied by the sum
of three unrelated floating point values which is extremely unlikely
to equal zero and would induce behavior that would look like a bug
if it did
- A corner cracking causes a one time spill (which is genuinely spooky)
and leaves a spooky-looking crack on the cracked corner, which does
nothing except prevent another spill unless you were dumb enough
to use a welder to repair it which would let it crack and spill again
That was probably not intentional
- So much code deduplicated, seeing just one place where production is
derived from fuel makes me very happy
- Moderator effects are now split into recipe specific and common
processing. Recipe specific processing takes the recipe as an
argument to make it easier to potentially run concurrent recipes
in the future.
- All three instances of hallucination inducing were different, such as
fusion level 3-4 being the only implementation that respects delta_time
- Computing nuclear particles to fire happened twice (one under another
never-fail power_output check)
- We retain distinct procs for damage/heal processing under SSair and
damage/heal processing under SSmachines. This is just so that this
refactor does not change behavior and is easier to validate
independent of functional fixes.
- Special behaviors at the end of common moderator processing are given
individual procs to make it very clear what is naughtily ignoring
delta_time
* HFR: Don't make iron without a reaction
* HFR: Fix crack oversight
There were no consequences to leaving a crack unfixed, and it would
leave the reactor immune to any later cracking
* HFR: Better commentary on damageheal
* HFR: Mitigate SSmachines and SSair drift
Also fix some of the more inane edge cases.
Fuel injection will now always keep up with fuel consumption, and
internal cooling will now always keep up with internal heating.
With that said, man, there are really no good solutions here.
There are two coherent options:
- Move everything to SSair
- Find a boundary where inter-subsystem drift is least awful
The first option is the only "real" option, in terms of whole-system
coherence. This is also the approach taken by the SM.
However, this exposes players to the peculiarities of tickrate in ways
even more blatant than the SM. Any SM interaction consists either of
checking that the heat is in the green, or interacting with smaller
atmos components around the SM in a frantic rush to fix things.
With the HFR, all interaction takes place via tgui, with very visible,
discrete updates timed with ui_data updates from the SSmachines tick.
The most important thing to learn when dealing with the HFR is that
with a maxed out heating conductor, the HFR will generate enough heat
to jump to the next fusion level in ~~two~~ one UI update (apparently
I learned mechanics when atmos was already running at half speed,
which at least serves to illustrate the problem), ignoring cooling or
unsatiated heat change.
Linking the speed of underlying changes to SSair instead of SSmachines
will almost certainly leave players with radically different impressions
of the HFR, depending on whether or not SSair is heavily yielding.
As small a slowdown as ~~0.5x~~ 0.25x will give players four UI updates
to handle the effects of a maxed out heating conductor, killing the
risk/reward dynamics and removing the most interesting question of any HFR
configuration - the soft cap of how wide a heating conductor one is
willing to set.
If using SSair has so many downsides, what is the alternative? Some
interaction with SSair is inevitable. We must connect to pipes and
link to external cooling at some point to be an atmos component at all.
The approach taken here is to say that external IO is the realm of
SSair, and all internal processing is the realm of SSmachines. This
isn't too bad, since most of the time an input port is fully saturated,
and output ports both drain as quickly as possible and don't spend much
time being examined by players.
Once at the edge buffers of the HFR, gas injection happens at a finely
controlled rate that already bears little resemblance to pressure
mechanics elsewhere in atmos. A fixed molar mass is transferred,
ignoring heat, pressure, and volume. This allows for finer control
of the fusion process, with most questions about the outside system
reduced to binary questions about other areas such as,
"is the incinerator still running and producing trit?", due to a
relatively low rate of consumption.
The elephant in the room is cooling. The cooling port needs to interact
with freezers or heat exchange pipes, and any configuration that tries
to push the envelope will care greatly about the relative capabilities
of heat produced and cooling provided.
Ultimately, this is the best approach for players. Subsystem drift
with heating/cooling mechanics is already a problem under the current
system, and worse due to internal cooling (but not heating!) happening
under SSair, too. Now, all visible gas production and consumption is
coherent. All but the most complex recipes under the more dangerous
settings have requisite knowledge about inter-subsystem tick drift removed,
needing little more than "is the space heat exchange grid still connected?"
To some extent, this could be mitigated by giving the fusion process more
control over its own cooling by reducing the penalty on endothermic reactions,
reducing dependence on external cooling on a distinct tickrate. This would
need careful design, however, and probably wants circuit integration
to make some of the logic automatable.
* HFR: Reorder main_processes/procs
* HFR: Rescale for unified system
Also attempt to fix what seem to be oversights:
- Halving the moderator and internal fusion injection rate makes them
line up with their stated units, but doesn't seem to be slower in
practice. Perhaps SSair was just yielding that much?
- The fusion mix reaching 10000 moles is extremely unlikely, but
the mechanics should operate properly if it does
- There was effectively no scaling on the overfull damage source,
this moves it somewhat closer to the original scale while still
making it easier
* HFR UI: Unconditionally update temperature
* HFR: Remove misleading comment
No public version of HFR code has produced gases while endothermic
* HFR: Production not affected by input modifier
Thinking about it, the top tier recipe having an effective output
modifier of x0.03 when it was listed as having an output modifier
of x0.01 is not very logical and was probably not intended
* HFR: Fix up some conditionals
The code that follows each check does nothing if the first branch failed,
and these conceptually make sense as && checks, so I'm assuming that this
was the intention.
* HFR: Don't evaporate at Fusion Level 0
There's no sense in evaporating from a dead reaction.
* HFR backend rework
Co-authored-by: esainane <esainane+github@gmail.com>
* The mole counts in the min checks in reactions.dm will now be multiplied by the inverse of the consumption multiplier. (#61557)
The moles in the min checks in reactions.dm will be multiplied by the inverse of the consumption multiplier. This will allow reactions to fully react when it has available gasses. It also makes some of the code easier to read.
Fixes (#61380)
From the issue report above:
Alright. So there's this pattern in reaction code
Looks like this
tgstation/code/modules/atmospherics/gasmixtures/reactions.dm
Lines 597 to 604 in 00154ae
var/nob_formed = min((cached_gases[/datum/gas/nitrogen][MOLES] + cached_gases[/datum/gas/tritium][MOLES]) * 0.01, cached_gases[/datum/gas/tritium][MOLES] * 0.1, cached_gases[/datum/gas/nitrogen][MOLES] * 0.2)
var/energy_produced = nob_formed * (NOBLIUM_FORMATION_ENERGY / (max(cached_gases[/datum/gas/bz][MOLES], 1)))
if ((cached_gases[/datum/gas/tritium][MOLES] - 5 * nob_formed < 0) || (cached_gases[/datum/gas/nitrogen][MOLES] - 10 * nob_formed < 0))
return NO_REACTION
cached_gases[/datum/gas/tritium][MOLES] -= 5 * nob_formed
cached_gases[/datum/gas/nitrogen][MOLES] -= 10 * nob_formed
cached_gases[/datum/gas/hypernoblium][MOLES] += nob_formed
We take the minimum of a few values, theoretically because we want the reaction to run with the lowest amount feasible.
So if there's 20 plasma, 10 o2, and 2 n2, and the reaction takes 4 parts plasma, 2 part o2, and 1 part n2, we'll only end up using 8 plasma, 4 o2, and 2 n2. Since we can't react without the n2 and all.
The if check is there to serve as a backup and prevent negative outputs, theoretically because they wreck havoc, though honestly they don't really, so long as the right bitflag is returned the whole mix is garbage collected anyway. Alright sanity check though. that's fine.
You notice how here, because he removes 5x nob formed from tritium, he includes that in the if check? If you scroll out to the right you'll notice that he multiplies the inputs in the min by the inverse of their scalar. At least that's what we want trying to do, mixed the two up.
You get the picture. The min serves to get the lowest possible amount to remove so the reaction can go through, and the if check serves as a sanity check wrapping around it.
The issue is people have been misusing it, for a good while. (Including in this instance)
They most commonly forget to include the inverse scaling in the min(), which leads to these weird fucked phantom gas minimums that aren't listed anywhere, but still stop the reaction.
See:
tgstation/code/modules/atmospherics/gasmixtures/reactions.dm
Lines 690 to 697 in 00154ae
var/heat_efficency = min(temperature * 0.3, cached_gases[/datum/gas/freon][MOLES], cached_gases[/datum/gas/bz][MOLES])
var/energy_used = heat_efficency * 9000
ASSERT_GAS(/datum/gas/healium, air)
if ((cached_gases[/datum/gas/freon][MOLES] - heat_efficency * 2.75 < 0 ) || (cached_gases[/datum/gas/bz][MOLES] - heat_efficency * 0.25 < 0)) //Shouldn't produce gas from nothing.
return NO_REACTION
cached_gases[/datum/gas/freon][MOLES] -= heat_efficency * 2.75
cached_gases[/datum/gas/bz][MOLES] -= heat_efficency * 0.25
cached_gases[/datum/gas/healium][MOLES] += heat_efficency * 3
They need to be updated to not do this, and use min() properly. It leads to dumb graphs like this https://www.desmos.com/calculator/xufgz8piqw (Healium formation graphed out. p is freon, b is bz. if either are reduced below 0, the reaction stops. If you notice this leads to really strange scaling deadspots, and a lot of frustrating behavior)
Thanks to @ GuillaumePrata for bringing this to my attention, love you man.
* The mole counts in the min checks in reactions.dm will now be multiplied by the inverse of the consumption multiplier.
Co-authored-by: Pickle-Coding <58013024+Pickle-Coding@users.noreply.github.com>
* Fix gases not having an overlay (#61732)
gas overlays were moved from new() to initialize() but they need to be made beforehand to properly work
(damn it cyber)
* Fix gases not having an overlay
Co-authored-by: Ghilker <42839747+Ghilker@users.noreply.github.com>
* Changes a bunch of New()s to Initialize()s (#61626)
* Changes a bunch of New()s to Initialize()s
Co-authored-by: Jordan Brown <Cyberboss@users.noreply.github.com>
* Fixes huge scrubbers using the portable icon instead (#61674)
Small atmos fix to make my day better!
* Fixes huge scrubbers using the portable icon instead
Co-authored-by: GuillaumePrata <55374212+GuillaumePrata@users.noreply.github.com>
* Fix Atmos Tanks Connecting to pipenets when mapped [MDB IGNORE] (#61646)
## About The Pull Request
Fixes#61594#59556 changed atmos tanks so that they do not automatically connect to adjacent pipes, but can support up to 4 directional connection, and merge with neighboring tanks to form one large one. Old tanks would connect based on their dir variable. New tanks would not. A work around was to varedit both dir *and* initialize_direction variables to the same value in the map editor - but this is not expected behavior for mapping.
This adds a check for mapload in the tank's initialize proc. If the tank is initializing during mapload, dir will be copied to initialize_directions (as it is in most other atmos devices), and the tank will connect in the specified direction(s).
The behavior of player constructed tanks is unchanged.
## Why It's Good For The Game
The primary purpose of these large, constructed atmos tanks is to provide a bulk source of gas to a map, such as a plasma tank for the incinerator, or air supply tanks to ruins or disconnected parts of the station. This enables them to be readily used for their purpose.
This fixes the 41 broken atmospheric tanks currently mapped in the codebase.
* Fix Atmos Tanks Connecting to pipenets when mapped [MDB IGNORE]
Co-authored-by: Maurukas <66576896+Maurukas@users.noreply.github.com>
* Adds the interrupt signal to the delay component, reorganises BCI files and circuit code improvements (#61393)
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Adds the interrupt signal to the delay component, reorganises BCI files and circuit code improvements
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* HFR: Fix T3 gas production at Fusion Level 2 (#61526)
I am once again asking you to observe the /tg/station13 codebase
MISSING ANOTHER [MOLES] AAAAAAAAAAA WHAT IS THIS JOKE OF A TYPE SYSTEM
* HFR: Fix T3 gas production at Fusion Level 2
Co-authored-by: esainane <esainane+github@gmail.com>
* HFR: Actually consume oxygen when mitigating iron (#61416)
fuck it's even worse than I realized in #61321
dumping a canister of oxygen into the moderator had it evaporate at
what looked like 10mol/s plus a bit of spare change for evaporation,
but it was actually all just evaporation all along
it didn't even runtime because of operator overloading aaaaaaaaaaaaa
* HFR: Actually consume oxygen when mitigating iron
Co-authored-by: esainane <esainane+github@gmail.com>
* adds logging for all canisters opened, logs all gases in spooky gas cans too (#61289)
admins are now alerted when miasma, freon, and co2 canisters are opened, and are informed of the contents of canisters containing dangerous gases in general, not just the spooky gas on its own.
added overall logging for all canisters opened
* adds logging for all canisters opened, logs all gases in spooky gas cans too
Co-authored-by: Mooshimi <85910816+Mooshimi@users.noreply.github.com>
* Fix HFR interface units (#61382)
* Fix HFR interface units
Exposing units in terms of tickrate to users shouldn't really happen,
but in this case the HFR also already respects delta_time for moderator
filtering rate.
See hfr_main_processes.dm:
```
moderator_internal.remove_specific(gas, (moderator_filtering_rate / filtering_amount) * delta_time)
```
Also consistently use `mol` over `g` for other types, and while the
typical equation symbol for Magnetic Flux Density is `B`, the SI unit
is Tesla (`T`).
* HFR: Fix fuel injection rate control
I don't know how this ever worked, but `remove_specific` already checks
to make sure that there is enough gas to remove, and caps appropriately.
With the lowest proportion possible (0.5 for both old and new units),
this very quickly absorbed all gas available from the fuel port. This
commit changes behavior so that the fuel injection rate is properly
respected.
* Fix HFR interface units
Co-authored-by: esainane <esainane+github@gmail.com>
* Actually fixes temperature pump exploit. Removes limit as it's redundant now. (#61406)
Temperature pumps were bugged and generated heat while exchanging heat. This fixes that and removes the limits as they were only used to stop people from creating infinite heat.
Exploit bad, and the limit was below a temperature that can be obtained legit(imately, which was annoying.
(I was initially against this pr, was under the impression that the heat pump actually pumped heat. apparently it doesn't. currently considering if it even needs to exist.)
* Actually fixes temperature pump exploit. Removes limit as it's redundant now.
Co-authored-by: 170141183460469231731687303715884105727 <58013024+170141183460469231731687303715884105727@users.noreply.github.com>
* Fix HFR Oxygen based iron content mitigation (#61321)
* Fix HFR Oxygen based iron content mitigation
Oxygen as an ameliorator for iron content buildup was added in 874914528.
However, the values used removed a breathtaking 50 percentage points of
iron content per tick (!) (note iron content is capped at 100 percentage
points!), at a cost of only 10 moles of Oxygen.
The overall effect is that non-debug HFR setups incidentally create
enough Oxygen to offset any iron content, and rarely risk meltdown.
This changes the values so that Oxygen is exactly enough to prevent
expected iron content buildup at fusion level 5, and slows buildup at
fusion level 6 to a mere 17% of the usual rate.
Oxygen consumed is now exactly proportional to the amount used to remove
iron, and delta_time is respected as well.
* Fix HFR Oxygen based iron content mitigation
Co-authored-by: esainane <esainane+github@gmail.com>
* Reorder HFR fuel datums (#61297)
* Reorder HFR fuel datums
This reorders the HFR datums in order of maximum temperature. This is
also a rough approximation of difficulty and order of desirability.
This mostly stops the plasma/oxygen recipe being a weird outlier in the
middle of the interface, but also somewhat makes the recipes above
make more sense too.
No functional changes.
* Reorder HFR fuel datums
Co-authored-by: esainane <esainane+github@gmail.com>
* HFR better moderator filtering (#61177)
Now you can choose multiple gases to filter from the moderators instead of just one and also the rate of filtering and you can filter even at power level 6. The rate is tied to the numbers of gases, so if you scrub at 200 moles/tick, and you have 5 gases selected, you'll be actually filtering at 40 moles/tick so be aware.
i've removed the antinob scrub since is redundant and broke the fuels.
UI renovation coming soontm
* HFR better moderator filtering
Co-authored-by: Ghilker <42839747+Ghilker@users.noreply.github.com>
* HFR moderator injection and fuel injection are now controlled separately (#61236)
better controls for atmos techs on the HFR inputs
* HFR moderator injection and fuel injection are now controlled separately
Co-authored-by: Ghilker <42839747+Ghilker@users.noreply.github.com>
* HFR more explosion difference between the various fuel mixes (#61242)
High effort HFR mixes should not have the same meltdown of the low effort ones, encourages the players to create high tiers mixes
* HFR more explosion difference between the various fuel mixes
Co-authored-by: Ghilker <42839747+Ghilker@users.noreply.github.com>
* Refactors how components are triggered and refactors how ports are ordered (#60934)
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Refactors how components are triggered and refactors how ports are ordered
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Free up smart pipe direction on disconnect (#61135)
Previously, a smart pipe that was attached in a given direction would
continue to hog that direction even if the attached piece was removed.
* Free up smart pipe direction on disconnect
Co-authored-by: esainane <esainane+github@gmail.com>
* Vents and scrubbers get unique name tags again (#61133)
You used to be able to mouse over a vent or scrubber to see its ID tag, in order to match it to its entry in an air alarm panel. However, this id tag is currently missing from the name.
* Vents and scrubbers get unique name tags again
Co-authored-by: esainane <esainane+github@gmail.com>
* large refactor of machine/power code to cut down on processing time and wasted lists (#60317)
original pr here: #59789 (Closed because he didn't think it was good enough)
came back to this because i realized that
all machines were area sensitive, meaning they had a list with at least a reference to themselves (assuming they arent in the contents of another movable which most arent) for the purposes of handling power differences when their area changes
pipes are machines
there are ~14k machines and ~6k pipes
i made this problem worse with a recent pr by making it a nested list
so i needed to track what machines needed power, and this pr had work already done that could be used for that purpose. now machines that have use_power == NO_POWER_USE do not have this extra memory overhead for no reason
currently every machine that uses power draws that amount from its area from a dynamic channel via auto_use_power() which is called every SSmachines fire(), then in apc/process() the area's dynamic power draw is reset and the power is used. with static power its not calculated then reset every loop, its just taken from the grid. so now machines handle updating their static power usage from their current area (this doesnt touch power machines that require a wire connection). in order to allow this, use_power, idle_power_usage, and active_power_usage have setters to track state correctly and update the static power usage on the machines current area and handle area sensitivity.
also goes through a lot of heavy abusers of SSmachine processing time and tries to make it faster. makes airalarm/process() into a signal handler for COMSIG_TURF_EXPOSE since air alarms only need to process for changes.
Why It's Good For The Game
SSmachines isnt the heaviest hitter in terms of total cpu and certainly not in terms of overtime, but its not a lightweight. it frequently takes > 50ms to complete a run and seems to be in the top 5 or so of subsystem costs looking at some round profilers
also gets rid of a few thousand lists since every pipe no longer has two useless lists each (and any other machines that dont use power)
Love ya kyler
Co-authored-by: Rohesie <rohesie@ gmail.com>
* large refactor of machine/power code to cut down on processing time and wasted lists
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
Co-authored-by: Rohesie <rohesie@ gmail.com>
Repaths everything referring to "toxins" while actually meaning either the room in science or plasma gas. While this PR might be disrespectful to our forefathers, given this is (I believe) a holdover from as far back as the Exadv1 days, this has constantly irked me since I started working with the code. None of the player-facing stuff has referred to plasma as toxin since before 4407 hit, besides the Toxins Lab, and yet all of the type-paths are still pointing at toxins, making it a nightmare to search for in a map editor, and making the code needlessly easy to confuse with that of toxin damage. So this just fires it into the sun.
Anything relating to Toxins, the science subdepartment, now makes reference to Ordnance instead. This felt fitting enough given the focus of the subdepartment is around the creation of and testing of explosives.
Anything relating to plasma gas has, fittingly, been made to refer to plasma gas.
Edit: Ah yes, I feel I should probably apologise off the bat for the size of this PR- the code touched is mostly atmos machinery and simplemobs, a few sprites here and there, and of course the station maps + a few offstation maps.
Makes the code more legible and makes mapping less painful.
(The payment has been made)
Co-authored-by: EOBGames <58124831+EOBGames@users.noreply.github.com>
Co-authored-by: Gandalf <jzo123@hotmail.com>
* small refactor to can_interact() so that borg range is fully respected (#60693)
Its a relatively small refactor that changes the previous machinery "can_interact()" proc that literally did a full override despite half of their checks already existing in not one, but TWO parent procs, so i removed the redundant checks, added callbacks to its parents and then added the cyborg range check on the can_interact_with() itself. in doing so i also moved the interaction range var from silicons only, to mobs as a whole and defaulted it to a single tile, silicons override it to 7 (so pAIs and borgs like before) but then set AI and AI.eye to "null", because i have a check in can_interact that if there is no range set, then the range is effectively unlimited. and i even added code for when AI is carded and their wireless transmission is disabled it sets their range to "0" aka, it has no range to do anything even if it could
this was really complicated for me so despite my extensive testing it probably would be a bad thing if any of you want to test my code yourself to ensure there isnt a bug with this (theres no runtimes ive come across)
note: i did a lot of searching and going through machinery to ensure i caught all the little snowflake overrides and added can_interact() checks to them, but i may have missed one or two things, especially maybe a altclick or ctrlclick somewhere, however i believe i caught most of them
one nice side effect of this refactor is that you can actually set another mobs range to something other than 1 tile and they can interact at range, rather than only silicons getting this ability, an admin could VV a human to have a 3 tile arm reach as a meme if they want
* small refactor to can_interact() so that borg range is fully respected
Co-authored-by: 小月猫 <alina.r.starkova@gmail.com>
