Fixes#62794 (Catwalk Tiles placed on the lower level of tram appear to be on the upper level)
Fixes#57654 (Open Space shading not always applied)
Fixes#53666 (When standing on a glass floor above a light on the Z level below you the light effect is rendered above the character. This makes light have ugly glows on the floors above. This also happens with grills and lattice.)
Transparent turfs, catwalks, and lighting overlays were badly broken with MultiZ issues. This fixes any transparent turf to appear and be on the same z-level if it has the turf_transparent element. Catwalks will appear and be on the same z-level as well. They were initially glitching to top z-levels causing people to walk over an illusion that caused them to fall to their deaths.
After I fixed these issues I noticed that lighting overlays were also glitching to top z-levels, which looked rather strange as there were lights in the middle of rooms and hallways with no supporting walls. Lights now appear under the transparent turfs properly.
The mapping icons for catwalks displayed the wrong icon_state so I fixed that too.
I made a big refactor for transparency and catwalks code that had to be done to get all of this to work properly.
You no longer have to be afraid of falling off of glass floors, catwalks, or transparent tiles. Also lighting overlays don't glitch through upper z-levels anymore for transparent tiles.
I'm refactoring proximity monitors and fields, removing lots of bloat from both that's hardly even used. Proximity monitors no longer generate effect objects to track the surrounding area, should be less cpu expensive and easier to maintain (or phase out), read and use.
This PR also adds a couple components which may be needed for future stuff (for starters, the mirror reflection PR #62638 could use the connect_range comp)
Improving old old, ugly old code and adding some useful backend components. Tested and working.
If there is no air on a turf, the supermatter crystal will not produce gases even if powered. This changes that so that it can produce gases while powered if there are none on the turf. It will still take damage in case it doesn't produce gases, or it gets immediately removed.
Although it's unlikely to happen, it will look very weird if the supermatter doesn't produce gas while on a non-space turf while powered, as that situation but with like 0.0001 moles on the turf would cause the SM to immediately go on fire.
a month or two ago i realized that on master the reason why get_hearers_in_view() overtimes so much (ie one of our highest overtiming procs at highpop) is because when you transmit a radio signal over the common channel, it can take ~20 MILLISECONDS, which isnt good when 1. player verbs and commands usually execute after SendMaps processes for that tick, meaning they can execute AFTER the tick was supposed to start if master is overloaded and theres a lot of maptick 2. each of our server ticks are only 50 ms, so i started on optimizing this.
the main optimization was SSspatial_grid which allows searching through 15x15 spatial_grid_cell datums (one set for each z level) far faster than iterating over movables in view() to look for what you want. now all hearing sensitive movables in the 5x5 areas associated with each spatial_grid_cell datum are stored in the datum (so are client mobs). when you search for one of the stored "types" (hearable or client mob) in a radius around a center, it just needs to
iterate over the cell datums in range
add the content type you want from the datums to a list
subtract contents that arent in range, then contents not in line of sight
return the list
from benchmarks, this makes short range searches like what is used with radio code (it goes over every radio connected to a radio channel that can hear the signal then calls get_hearers_in_view() to search in the radios canhear_range which is at most 3) about 3-10 times faster depending on workload. the line of sight algorithm scales well with range but not very well if it has to check LOS to > 100 objects, which seems incredibly rare for this workload, the largest range any radio in the game searches through is only 3 tiles
the second optimization is to enforce complex setter vars for radios that removes them from the global radio list if they couldnt actually receive any radio transmissions from a given frequency in the first place.
the third optimization i did was massively reduce the number of hearables on the station by making hologram projectors not hear if dont have an active call/anything that would make them need hearing. so one of hte most common non player hearables that require view iteration to find is crossed out.
also implements a variation of an idea oranges had on how to speed up get_hearers_in_view() now that ive realized that view() cant be replicated by a raycasting algorithm. it distributes pregenerated abstract /mob/oranges_ear instances to all hearables in range such that theres at max one per turf and then iterates through only those mobs to take advantage of type-specific view() optimizations and just adds up the references in each one to create the list of hearing atoms, then puts the oranges_ear mobs back into nullspace. this is about 2x as fast as the get_hearers_in_view() on master
holy FUCK its fast. like really fucking fast. the only costly part of the radio transmission pipeline i dont touch is mob/living/Hear() which takes ~100 microseconds on live but searching through every radio in the world with get_hearers_in_radio_ranges() -> get_hearers_in_view() is much faster, as well as the filtering radios step
the spatial grid searching proc is about 36 microseconds/call at 10 range and 16 microseconds at 3 range in the captains office (relatively many hearables in view), the new get_hearers_in_view() was 4.16 times faster than get_hearers_in_view_old() at 10 range and 4.59 times faster at 3 range
SSspatial_grid could be used for a lot more things other than just radio and say code, i just didnt implement it. for example since the cells are datums you could get all cells in a radius then register for new objects entering them then activate when a player enters your radius. this is something that would require either very expensive view() calls or iterating over every player in the global list and calling get_dist() on them which isnt that expensive but is still worse than it needs to be
on normal get_hearers_in_view cost the new version that uses /mob/oranges_ear instances is about 2x faster than the old version, especially since the number of hearing sensitive movables has been brought down dramatically.
with get_hearers_in_view_oranges_ear() being the benchmark proc that implements this system and get_hearers_in_view() being a slightly optimized version of the version we have on master, get_hearers_in_view_as() being a more optimized version of the one we have on master, and get_hearers_in_LOS() being the raycasting version currently only used for radios because it cant replicate view()'s behavior perfectly.
About The Pull Request
Now that radiation waves are gone, the SM isn't capable of generating Pluox, actually the only way to generate Pluoxium is with a reaction mix of O2/Plasma/Tritium at low pressure, something that I assume most of the Atmos players don't even know about as the SM was the main and efficient way to generate Pluox.
The change also removed Pluox as an annoying waste gas on the SM, not the biggest of nerfs but...
So I copied the way the SM reacts with Miasma to generate extra power (bet most people don't know about this either.) for parity on how the SM only reactions work, but with a few changes to work better with a high power charged CO2 SM compared to a Miasma one.
The main change compared to the Miasma reaction is that it scales less with power and more with pressure, a High pressure and low power CO2+O2 SM should be the most efficient/safe way to make Pluox, a different kind of challenge to the low pressure high power CO2 SMs we have already.
Also, the amount of Pluox generated might need tweaks, but it is nothing compared to the production of old Radiation charged SMs.
Why It's Good For The Game
When I was a lil baby Atmos Tech, I looked at the Pluox generation reaction and had such high expectations.
"Wow, I can make more efficient Pluox internals to give away, I can flood the Station with Pluox instead of O2 and it will prevent fires and allow Plasmamen to vibe!"
Such cute thoughts that never really got into reality because the task is gargantuan without much return... still cute thoughts that I hope new Atmos players at least try.
Something something S O U L.
Changelog
cl Guillaume Prata
expansion: After a short break, the Supermatter is back again at the her hard working and slightly different Pluoxium generation business.
/cl
This apparently happened in 58d0f12c5c, four year ago, where a New()
was renamed to Initialize().
Apparently in this case, the second definition runs first, and the first
definition runs in the second's parent call. Since the second immediately
calls the first as a parent call, just merging them with the first's body
first preserves behavior.
This is slightly horrifying.
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
Implements the Modernizing radiation design document ( https://hackmd.io/@tgstation/rJNIyeBHt ) and replaces the current radiation sources with the new system, as well as replacing/removing a bunch of old consumers of radiation that either had no reason to exist, or could be replaced by something else.
Diverges from the doc in that items radiation don't go up like explained. I was going to, but items get irradiated so easily that it just feels pretty lame. Items still get irradiated, but it's mostly just so that radiation sources look cooler (wow, lots of stuff around going green), and for things like the geiger counter.
Instead of the complicated radiation_wave system, radiation now just checks everything between the radiation source and the potential target, losing power along the way based on the radiation insulation of whats in between. If this reaches too low a point (specified by radiation_pulse consumers), then the radiation will not pass. Otherwise, will roll a chance to irradiate. Uranium structures allow a delay before irradiating, so stay away!
So, uh, well, basically, the condition was checking for something that was true in BYOND's terms when it shouldn't've been. Whoops!
We all love working power, don't we?
Fixes#62446 (Not being able to place cables at all)
Turfs have a variable, intact, which conflates three meanings:
Determining whether there's something that can be pried out, such as directly with a crowbar or indirectly with a tile stack and a crowbar off-hand.
Determining whether underfloor pieces are visible.
Determining whether underfloor pieces can be interacted with - by players with tools, through interaction with effects like chemical acid, or foam.
When plating is hit with a stack of tiles, /turf/open/floor/attackby checks whether the turf is intact, and if so, ends the attack chain regardless of whether or not the attempt to hotswap a turf (with a crowbar) is successful or not. However, turfs which want the underfloor to be visible - such as catwalks and glass - set the intact variable to FALSE, and so can be repeatedly placed over one another, as if they were the first tile to be placed over the plating.
This refactors /turf/var/intact into two distinct variables:
/turf/var/overfloor_placed, for whether or not there is something over plating.
/turf/var/underfloor_visible, for whether or not the various underfloor pieces should be invisible, visible, or both visible and interactable.
All references to /turf/var/intact have been replaced with an equivalent overfloor_placed or underfloor_visible reference, depending on which check is appropriate. underfloor_accessibility can take one of UNDERFLOOR_HIDDEN, UNDERFLOOR_VISIBLE, or UNDERFLOOR_INTERACTABLE. This prevents cases such as acid foam or tools phasing through glass floors to affect the underfloor pieces underneath, and covers all kinds of unusual, not-wiring-visiblity usage such as Holodeck completeness, Revenant interaction, or station integrity checking.
* SM: Fix pressure bonus system
Fixes#62124 (Pressure wasn't actually doing anything)
> This is a multiplier meant to be used at low pressures.
> The lower the pressure the higher the multiplier.
> This is to encourage low pressure setups and so cold setups.
> At higher pressures (from around 100 kpa and up) it will max to 1
Current behavior is what follows.
As pressure drops, the multiplier remained at 1 until it dropped to 5.96kPa.
It then very marginally increased until it reaches x1.17 at 0kPa.
This commit introduces a system that solves the constants for the equation
based on human readable parameters, and sets provisional parameters for it. Also makes behavior better match the stated intent.
You can varedit the parameters to see the real effects of changes, just be
sure to proc call update_constants().
Constants default to what amounts to 0 so it fails loud (I WANT TO HEAR SUFFERING -Lemon)
Makes the American sausage a proper subtype of sausage, which makes it actually edible, apparently. It also makes it stick on the advanced roasting stick!
The advanced roasting stick will no longer try to grill itself over a bonfire with a griddle installed, allowing you to use the actual bonfire for your roasting needs.
There was actually a check that was supposed to limit the amount of times you could roast a sausage to a measly 1. It wasn't actually working. This PR removes that in favor of mad cooks creating these:
* Energy collection: Mass rework
Radiation Collectors and Tesla Coils are now subtyles of a common
energy_accumulator type. This type combines common code such as smoothing
output over energy received, computing power output, and handling wire
connections.
Inline calculations using machine energy units are now performed by
common math functions in maths.dm. Rather than reference 0.1,
1 SECONDS is used to make it clear this is to calculate to and from
tickrate dependent units.
Constants which are written in terms of tickrate dependent units are now
written in terms of joules, and use these helpers to convert to and from
these units. With SSmachines.wait / (1 SECONDS) being 2, this usually
means doubling the values of constants which were previously defined in
terms of machine energy units.
* Energy collection: Map path update
> git ls-files | grep dmm | xargs sed -i 's1rad_collector1energy_accumulator/&1g'
> git ls-files | grep dmm | xargs sed -i 's1tesla_coil1energy_accumulator/&1g'
> git ls-files | grep dmm | xargs sed -i 's1grounding_rod1energy_accumulator/&1g'
Supermatter forked lightning can now hit targets previously used by a sibling.
The default setup - and anything using two grounding rods - was still entirely safe, as "pass by ref begone" code did allow target reuse in ancestors. Any split could only exclude one grounding rod, and if one branch split again, neither branch's targets would be passed back to the target list of the first split.
The same issue was not present in `proc/tesla_zap`. Probably still shouldn't have two of these, though.
major cleanup of modules/atmospherics folder and all related files, still many missing
-cleanup of procs name
-cleanup of vars name
-documentation of some of the procs
-minor changes to some for() logic (no in game changes just early continue or as anything checks)
No in game changes, only code and docs
Add a calculation to the coil sound and extrarange so that they are not deafening
Thanks to the discord user @hawk#1896 for the sound calculations
Less deafening sounds and better feedback to the players (louder zaps mean higher power output)
Previously, a hostile statue could move it by bumping into it. It would
still be dusted, but this left open the possibility of supposedly
immobile engines moving, albeit slowly and expensively.
Previously, a hostile statue could move it by bumping into it. It would still be dusted, but this left open the possibility of supposedly immobile engines moving, albeit slowly and expensively.
Hostile Statues have a move_force of 9000, but continued to be able to bump the SM until move_force was varedited to 1999 or below. This means (at least) immovable rods and all megafauna could all bump an "immobile" SM one tile per life.
bring code up to latest standards, move many procs to named files inside _HELPERS
no idea where to put some of these procs, help is appreciated
made more files to contain some unique code, deleted unsorted.dm, we can rest now
Fixed the cable restraints not showing up in the radial crafting menu. This was caused by the cable restraint (cuff) icon being moved to the restraint.dmi file - I didn't see this old reference elsewhere in the code. (first TG commit, please let me know if I am missing anything.
About The Pull Request
for(var/obj/machinery/power/apc/APC in GLOB.apcs_list) in get_apc makes chuck norris shed a tear
Why It's Good For The Game
tears are bad
Changelog
cl
code: /area now retains a local reference to the APC in the area, if any
/cl
What does the PR do
This reworks how our rendering is handled, specifically moves away from plane masters as the end solution:
Instead we replace plane masters rendering directly to client with planes that render multiple planes onto them as objects in order to be able to affect multiple planes while treating them as a single object. This is done by relaying the plane using a "render relay" onto a "render plate" which acts as a plane master of plane masters of sorts, and since planes are rendered onto it as single objects any filters we apply to them will render over the planes, treating them as a single unit
image
Also cleaned up unused plane masters and render targets to reduce clutter, as well as removing a useless filter that was resulting from confusion due to said clutter.
Clientside performance testing showed no significant change, no effect on serverside performance as this is clientside.
Also added the blackness plane master so it can be relayed, side effect is that it can now be used to adjust how blackness is rendered
P2 should introduce rendering one plane to multiple render_plates, but i want to get this done before I finish that, though testing shows its feasible
Why It's Good For The Game
Allows more advanced effects.
As an example i made a grav anomaly effect in like 30 seconds for this video i will improve it once im awake properly:
https://streamable.com/lu98dz
Documentation images should be merged here after this pr is done
tgstation/documentation-assets#2
Changelog
cl
qol: grav anomalies now have a pretty effect
refactor: Rendering has been refactored, remember to report bugs
/cl
## About The Pull Request
stop forgetting to include mapload, if you don't include it then every single subtype past it by default doesn't include it
for example, `obj/item` didn't include mapload so every single item by default didn't fill in mapload
## Regex used:
procs without args, not even regex
`/Initialize()`
procs with args
`\/Initialize\((?!mapload)((.)*\w)?`
cleanup of things i didn't want to mapload:
`\/datum\/(.)*\/Initialize\(mapload`
Someone forgot to add GLOB.cult_narsie so I think what would happen is, despite narsie being dead, the shuttle wouldn't leave.
Was a non issue because the round ends if nar nar is last minute killed. There is not enough time for the shuttle to even leave.
That said, unimportant failures are still failures, so let's get going
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>
