* Adds lag compensation for the supermatter zaps and some antagonists. (#78174)
## About The Pull Request
Adds delta time scaling for changeling chemical generation, xenomorph
plasma generation, xenomorph resin healing (up to 8 seconds per tick to
prevent weird instant heal phenomena in extreme cases), and revenant
essence generation. This delta time scaling is based on the world's time
and the respective subsystem's last fire. This will help keep these
generation smooth even when their respective subsystem lags, preventing
lag from ruining the antagonists rounds. This can still slow down if the
actual world is slowing down, but that's fine because the rest of the
world will typically be slowing down proportionately so it's fair.
Fixes supermatter zap rate not scaling with its internal energy
properly. Ghilker forgot to scale the time reduction by seconds. It
should be much faster at higher energy levels, making the transition
between 0 and 5 GeV more smooth.
Supermatter zap power generation will scale by the world's delta time
between the supermatter's last zap, making power generation more
consistent even when atmos lags. Also prevents the supermatter zap rate
scaling from also scaling the power generation by extreme amounts,
keeping it linear and consistent for the first 5 GeV (>5GeV has cringe
power multipliers, but I'm going to ignore that for this PR, because I
want this to mainly be a consistency thing rather than a balance thing).
A 1.5GeV supermatter will be able to generate around 800kW* of power. I
forgot exactly what goal of power we want the roundstart SM to produce,
so I might change the scale if I find the target power generation.
* - By generate 800kW of power I mean the energy the actual zaps
contain. Tesla coils don't collect 100% of it. I'll test later to see
how much an actual roundstart SM will output to grid (ignoring SMES),
and I'll try to keep it as close as possible to what it was before this
PR assuming no lag.
## Why It's Good For The Game
Subsystems can disproportionately lag a lot more compared to the rest of
the subsystems and game. This can ruin antagonist rounds as it can slow
their chemicals, plasma or whatever generation grinding to a halt. The
delta time scaling will significantly reduce the impact of lag for these
antagonists, allowing them to play more normally even while the
subsystems their generators run on are lagging.
Supermatter zap rate was supposed to fire every 2.5 or something seconds
at 1.5GeV according to comments on older commits. I just assume they
accidentally forgot to scale their time reduction by seconds, as doing
that made it work accordingly.
For supermatter zap power generation delta time scaling, kinda same
reasoning as for the antagonists. We don't want power generation to stop
because atmos ss is being slow. Scaling between the zaps also prevents a
nonlinear boost to power generation making it even more absurd at higher
energy levels.
## Changelog
🆑
balance: Supermatter zap power generation scales with the delta time
between its last zaps, preventing faster zapping from scaling power
generation to extreme levels.
fix: Fixes supermatter zap rate not scaling properly. It should zap much
faster at higher energy levels as intended.
qol: Changeling chemical generation scales with the world's delta time,
making its rate independent of subsystem lag.
qol: Revenant essence generation scales with the world's delta time,
making its rate independent of subsystem lag.
qol: Xenomorph plasma generation and resin healing scales with the
world's delta time, making their rates independent of subsystem lag.
/🆑
* Adds lag compensation for the supermatter zaps and some antagonists.
---------
Co-authored-by: Pickle-Coding <58013024+Pickle-Coding@users.noreply.github.com>
* Supermatter delam common radio alert cooldown (#78104)
## About The Pull Request
Changes the supermatter radio alert to be less spammy while the crystal
is healing during recovery.
If the crystal is in a state of fast healing (defined as 3% per minute,
about half of a crystal's 6%/min recovery at 293K) we're in a situation
where the engineers have prevented the delam and the crystal is
returning to normal.
In these situations the Common radio channel doesn't need to be reminded
every 60 seconds that the crystal is more than fine and on its way back
to 100, a cooldown is started for the Common channel alerts. Engineers
continue to get the integrity update every 60 seconds as usual on their
departmental channel.
The cooldown is only applicable to when the crystal is healing, if
integrity starts dropping again below the emergency point Common will be
alerted.
The command span is added for the final countdown only (from
https://github.com/tgstation/tgstation/pull/77996)
## Why It's Good For The Game
The SM alerting on Common every 60 seconds as it heals leads to alarm
fatigue and you tune it out. It should only be alerting Common when
there is imminent danger to the crew or that the danger has passed.
## Changelog
🆑 LT3
qol: Supermatter common channel alerts are less frequent if the
crystal's integrity is rising rapidly
/🆑
* Supermatter delam common radio alert cooldown
---------
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* Move some job related achievements into the job achievement category (#78092)
## About The Pull Request
Read title, this only affects the UI and not the database as far as I am
aware
## Why It's Good For The Game
The jobs category is painfully empty, only being home to four
achievements total. Meanwhile we have a ton of achievements inside the
miscellaneous category, a lot of which are not miscellaneous
achievements at all. Right now I just wanna focus on moving around
achievements from existing category to existing category though. This
improves achievement category spread overall by a small but necessary
amount.
## Changelog
🆑 distributivgesetz
code: Moved some job-related achievements from the misc category to the
jobs category.
/🆑
* Move some job related achievements into the job achievement category
---------
Co-authored-by: distributivgesetz <distributivgesetz93@gmail.com>
* Progress bars & cleaning particles will centre on the tile occupied by large icon objects (#77940)
## About The Pull Request
Do_after bars always draw based on the top-left corner of the targetted
atom, for atoms with sprites that are larger than 32x32 this gives them
a weird offset instead of being centred, which bugs me.
I have tried my best to figure out a way to reverse this which does not
interfere with atoms which use pixel_x/pixel_y to visually appear to be
on a different tile.
## Why It's Good For The Game
Before:
he hates how you missed him completely 😦
After:
now you're cleaning his feet 🙂
## Changelog
🆑
image: progress bars and cleaning particles are now centered on the tile
occupied by the target, if it is a big sprite
/🆑
* Progress bars & cleaning particles will centre on the tile occupied by large icon objects
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* Adds an achievement for saving a cascading SM from the final countdown. (#77900)
## About The Pull Request
Adds the "All Within Theoretical Limits" achievement. You get the
achievement for standing inside the engine room at the time where the SM
crystal heals from 0% health (when the crystal says "Crystalline
hyperstructure returning to safe operating parameters. Harmonic
frequency restored within emergency bounds. Anti-resonance filter
initiated"), and waiting until the SM heals to at least 25% health.
## Why It's Good For The Game
This rewards engineers who stay behind and try to save the engine even
in the most dire circumstances.
## Changelog
🆑 distributivgesetz
add: Add an achievement for saving a cascading engine from the final
countdown.
/🆑
* Adds an achievement for saving a cascading SM from the final countdown.
---------
Co-authored-by: distributivgesetz <distributivgesetz93@gmail.com>
* Multitool can be used to access APC/Teslacoil/SMES/emitter internal wires (#77790)
## About The Pull Request
adjusted /obj/machinery/power/multitool_act to no longer return
successful for all return paths. allowing attack_chain to continue and
eventually hit the machine's attackby function and access machine wires
## Why It's Good For The Game
Multitool opens wire UI on doors and air alarms, it should be consistent
with other machines with wires.
## Changelog
🆑
fix: multitool can be used on APC/Teslacoil/SMES/emitter if it has
exposed wires.
/🆑
* Multitool can be used to access APC/Teslacoil/SMES/emitter internal wires
---------
Co-authored-by: Redbert <109347230+Deadgebert@users.noreply.github.com>
* Remove unused override comments and fix a few I found
* remove lighting icon overrides (obsolete)
* remove laz/borg overrides (obsolete)
* Remove the catch-all e-gun override, manually overrides the two severely out of date sprites that we ACTUALLY have updates for
* oop
* removes obsolete surgery table sprite (probably technically too close to Bay's to be using actually)
* Love un-updated pathing
* oop
* this back icon wasn't even on this gun ever was it
* didn't notice this override >:(
* Fixes cost values of RCDs (#77650)
## About The Pull Request
fixes cost values to be 1:1 of what the construction would have costed
in manual construction for the RCD. also changes all decaseconds to
seconds in code for clarity.
the biggest change is windows, they used to cost more than they needed
for manual construction:
grille - 4mu - 1 iron sheet - 100% efficiency
directional normal window - 6mu - 1 glass sheet - 66% efficiency
directional reinforced window - 9mu - 1 reinforced glass sheet - 66%
efficiency
fulltile normal window - 12mu - 2 glass sheets - 66% efficiency
fulltile reinforced window - 15mu - 2 reinforced glass sheets - 80%
efficiency
this PR fixes all of these to be 100% efficient by lowering their matter
costs, among some other items like racks or reflector frames.
## Why It's Good For The Game
consistency for material costs is good. most of these incorrect material
values are also for things that don't matter, like racks or reflector
frames. also decaseconds are gross looking in code
## Changelog
🆑
fix: Some RCD constructs took more material than manual construction.
The RCD cost should be consistent in comparison to manual construction
now.
/🆑
* Fixes cost values of RCDs
---------
Co-authored-by: iwishforducks <65363339+iwishforducks@users.noreply.github.com>
* MODLink System (+ NWTLMM) (#77639)
## About The Pull Request
A pact made with `@ Kapu1178`
Small changes you should not care about:
RD MODsuit outfit (admin only) no longer has a beret that blocks the
activation of the suit
The beret used by death squad officers no longer is blocked from being
put on a hat stabilizer module
Admins can now Shear matrices of objects in Modify Transform
Multitool buffers have been a little refactored to use a setter proc
that saves them from causing hard dels
Cooler stuff:
A revival and remake of [Nobody Wants To Learn Matrix
Math](https://github.com/tgstation/tgstation/pull/59103), this time with
additional tooling for quick matrix calculations.
The MODLink system, available through every MODsuit and MODLink scryers
(a neck item obtainable from advanced modsuit research or
charliestation)
Let's you make a holographic call with any other MODLink user, where you
can chat in realtime and see what's up with em
## Why It's Good For The Game
Adds a fun way for the crew to communicate with each other that can be
done in real-time with relative privacy compared to radio.
## Changelog
🆑 Fikou, Armhulen, Sheets (+rep for Mothblocks and Potato)
fix: RD MODsuit outfit (admin only) no longer has a beret that blocks
the activation of the suit
fix: The beret used by death squad officers no longer is blocked from
being put on a hat stabilizer module
admin: Admins can now Shear matrices of objects in Modify Transform
admin: Admins now have access to Test Matrices in the VV dropdown, an
all-in-one tool for editing transforms.
add: MODLink system, available through scryers (from RnD and Charlie
Station) and through MODsuits. Lets you call people with holographs!
/🆑
* MODLink System (+ NWTLMM)
---------
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
* Refactors Regal Rats into Basic Mobs (more titles edition) (#77681)
## About The Pull Request
I literally can't focus on anything nowadays, so I just did this to
break a never-ending chain of distress. Anyways, regal rats! These
fellas are mostly player controlled, but did have _some_ AI capabilities
(mainly tied to their actions), so that was incorporated too. Everything
should work as-expected (as well as look a shitload cleaner).
Instead of doing weird and awful conditional signals being sent out, I
made the `COMSIG_REGAL_RAT_INTERACT` (not the actual name) have a return
value so we can always rely on that working whenever we have that signal
registered on something we attack. I also cleaned up pretty much every
proc related to regal rats, gave them AIs to reflect their kingly nature
(and action capabilities (as well as move the action to
`mob_cooldown`)).
Since I thought they needed it, Regal Rats now get a special moniker!
This is stuff like "the Big Cheese" and what-not, like actual regents in
history. That's nice.
## Why It's Good For The Game
Two more off the list. Much better code to read. Way smarter rats with
spawning their army as part of a retaliatory assault (war). More sovl
with better regal rat names. The list goes on.
## Changelog
🆑
refactor: Regal Rats have been refactored into basic mobs. They should
be a bit smarter and retain their docility (until attacked, in which
case you should prepare to get rekt by summoned rats), and properly flee
when they can instead of just sit there as you beat them to death. The
framework for them interacting with stuff (i.e. opening doors while
slobbering on food) is a bit more unified too, now. They also have
cooler names too!
/🆑
FYI: Beyond a few code touchups, I haven't touched the actions at all. I
do not believe myself to be enthusiastic about fixing anything involving
the actions code as of this moment so that this PR is more overbloated
unless it's unbelievably stupid or easy to fix.
* Refactors Regal Rats into Basic Mobs (more titles edition)
---------
Co-authored-by: san7890 <the@san7890.com>
* Add admin blackhole(s) shuttle event (#77188)
## About The Pull Request
This adds a new **Black Hole** admin shuttle event while the escape
shuttle is in transit. The regular version spawns a small 1x1
singularity that falls through the ship. There is also a special
adminbus Kobayashi Maru version that spawns multiple black holes
rapidly.
## Why It's Good For The Game
Tell me this doesn't look fun?
## Changelog
🆑
add: Add admin blackhole shuttle event with a normal version and
suicidal version.
fix: Fix several shuttle event runtimes
/🆑
---------
Co-authored-by: Time-Green <7501474+Time-Green@ users.noreply.github.com>
* Add admin blackhole(s) shuttle event
---------
Co-authored-by: Tim <timothymtorres@gmail.com>
Co-authored-by: Time-Green <7501474+Time-Green@ users.noreply.github.com>
* Autowiki Stock Parts Template (#76765)
## About The Pull Request
Autowiki functionality for stock parts
stockparts.dm extends the autowiki datum, implementing multiple
functions to upload images of and parse information about all the
craftable stock parts in the game a player is likely to encounter.
The template can be called on the wiki by using
`{{Autowiki/Content/StockParts}}`
[VIEW OUTPUT
HERE](https://tgstation13.org/wiki/Template:Autowiki/Content/StockParts)
## Why It's Good For The Game
Better documentation means lower learning curve, items that are properly
up-to-date is a good start.
This will probably branch into a few other autowiki additions for the
other various items from research, has the potential to lead to a full
documentation of the autolathe if done correctly.
## Changelog
:cl:Senefi
code: Autowiki module for stock parts
fix: Emergency lights no longer runtime when created in nullspace
/🆑
* Autowiki Stock Parts Template
---------
Co-authored-by: Senefi <20830349+Peliex@users.noreply.github.com>
* Doubles the time you can get the "Long shift" achievement, makes it not grant on admin restarts (#77195)
## About The Pull Request
- "Long shift" can now be earned from sub 10 minute rounds rather than
sub 5 minute rounds
- Admin restarts no longer give out "Long shift"
## Why It's Good For The Game
I do not think this achievement can *possibly* be earned right now. Like
at all.
Nuke Ops and cult are the only antags that can possibly do it and it's
incredibly infeasible (requiring that they nuke the station or summon
Nar'sie in just 3 minutes!)
So I bumped up the timer to 10 minutes. This means that ops can get it
if they nuke the station in 8 minutes, cult can get it if they REALLY
speedrun, and revs can get it if they beeline the heads.
I checked the DB for stats on this achievement and it's only been earned
in 3 rounds across the last year - `208780` (admin restart due to a bug)
`192892` (admin restart due to a bug?) `186192` (admin restart).
So I also prevented admin forcing the round to end. (I don't know if it
catches admin reboots directly I'll have to check that.)
## Changelog
🆑 Melbert
balance: The "Long Shift" achievement is now feasibly obtainable, and
admins can no longer trigger it unknowingly
/🆑
* Doubles the time you can get the "Long shift" achievement, makes it not grant on admin restarts
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Implements usage of the REVERSE_DIR macro throughout the code. (#77122)
## About The Pull Request
Replaces a ton of `turn(dir, 180)` calls with the aforementioned macro.
## Why It's Good For The Game
Afaik, `REVERSE_DIR` was coded to be faster than the classic `turn(dir,
180)` call, being a simple set of binary operations. To sum it up, micro
optimization.
## Changelog
N/A
* Implements usage of the REVERSE_DIR macro throughout the code.
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* Metastation Medbay Lighting Tweaks (#77012)
## About The Pull Request
Adjusts some of the lights in metastation medbay to improve overall
theming of specific rooms.
Rooms changed:
- Morgue
- Medbay Hallway
- Cold Storage
- Chem Storage
- Break Room
- Clinic
- Primary Surgical Theatre
- Psychiatrists Office
This makes use of a new preset, Dim Cold Lights, and also implements a
Dim Warm Light counterpart.
## Why It's Good For The Game
More presets for mappers to use for lights, and subtle changes to the
lights in medbay to make each light feel more impactful, darkening the
rooms more when lights break and improving the overall theme of specific
rooms via the use of color temperature and intensity.
## Changelog
:cl:Senefi
add: Some Metastation Medbay lights have been moved and adjusted.
/🆑
* Metastation Medbay Lighting Tweaks
---------
Co-authored-by: Senefi <20830349+Peliex@users.noreply.github.com>
* Make electrified grilles, APCs, SMES and buckled stuff shock as expected again (#77004)
## About The Pull Request
Fixes some issues form the #76075 rework.
1. Grilles didn't shock anymore unless placed on red (layer 1) wire. Now
it looks for any of the three layers.
2. APCs also didn't get the correct cable layer for shocking as you
build a terminal. So they wouldn't shock you if there wasn't a layer 1
cable that carried power. And no one ever uses layer 1 cables sadly. Now
they look for the cable layer you're building the terminal on.
3. SMES, like APCs, didn't check for the correct cable layer when
building a terminal. Now they do.
4. As far as I can tell, gas miners would also only have worked on cable
layer 1, now they work on all layers.
This is because before the #76075 rework, all machinery connected to a
"machinery" cable layer instead of an actual cable layer.
The reworks' `get_cable_node` assumes `CABLE_LAYER_1` as a default
parameter, causing only red cables to connect when no parameter is
passed, unlike before where all cables would connect.
The rework adjusted some machines to be able to connect to a specific
layer. But I think other "machines" such as grilles should just us all
layers available. So I adjusted the `get_cable_node` to look for all
layers unless a specific layer is specified in the call
## Why It's Good For The Game
Rage cages good
Maint shocking grilles good
No one knows to use red cable to shock stuff
🆑
fix: Cable connections on various structures including electrified
grilles, APC terminals, and SMES terminals have been rectified and will
shock as expected again.
fix: Gas miners draw power properly again.
/🆑
* Make electrified grilles, APCs, SMES and buckled stuff shock as expected again
---------
Co-authored-by: Inari-Whitebear <inari_whitebear@fastmail.jp>
* [MDB IGNORE] Angled Lights & Lighting Prototyping Tool (#74365)
## About The Pull Request
Hello friends, I've been on a bit of a lighting kick recently, and I
decided I clearly do not have enough things to work on as it is.
This pr adds angle support to static lights, and a concepting/debug tool
for playing with lights on a map.
Let's start from first principles yeah?
### Why Angled Lights?
Mappers, since they can't actually see a light's effect in editor, tend
to go off gut.
That gut is based more off what "makes sense" then how things actually
work
This means they'll overplace light sources, and also they tend to treat
lights, particularly light "bars" (the bigger ones) as directional.
So you'll have two lights on either sides of a pillar, lights inside a
room with lights outside pointing out, etc.
This has annoying side effects. A lot of our map is overlit, to the
point that knocking out a light does.... pretty much nothing.
I find this sad, and would like to work to prevent it. I think dark and
dim, while it does not suit the normal game, is amazing for vibes, and I
want it to be easier to see that.
Angled lights bring how lights work more in line with how mappers expect
lights work, and avoids bleedover into rooms that shouldn't be bled
into, working towards that goal of mine.
### How Angled Lights?
This is more complex then you'd first think so we'll go step by step
Oh before we start, some catchup from the last time I touched lighting
code.
Instead of doing a lighting falloff calculation for each lighting corner
(a block that represents the resolution of our lights) in view we
instead generate cached lightsheets. These precalculate and store all
possible falloffs for x and y distances from a source.
This is very useful for angle work, since it makes it almost totally
free.
Atoms get 2 new values. light_angle and light_dir
Light angle is the angle the light uses, and light_dir is a cardinal
direction it displays in
We take these values, and inside sheetbuilding do some optional angle
work. getting the center angle, the angle of a pair of coords, and then
the delta between them.
This is then multiplied against the standard falloff formula, and job
done.
We do need some extra fenangling to make this all work nicely tho.
We currently use a pixel turf var stored on the light source to do
distance calculations.
This is the turf we pretend the light source is on for visuals, most
often used to make wall lights work nice.
The trouble is it's not very granular, and doesn't always have the
effect you might want.
So, instead of generating and storing a pixel turf to do our distance
calculations against, we store x and y offset variables.
We use them to expand our working range and sheet size to ensure things
visually make sense, and then offset any positions by them.
I've added a way for sources to have opinions on their offsets too, and
am using them for wall lights.
This ensures the angle calculations don't make the wall behind a light
fulldark, which would be silly.
### Debug Tool?
In the interest of helping with that core problem, lights being complex
to display, I've added a prototyping tool to the game.
It's locked behind mapping verbs, and works about like this.
Once the verb is activated, it iterates over all the sources in the
world (except turfs because those are kinda silly), outlining and
"freezing" them, preventing any future changes.
Then, it adds 3 buttons to the owners of a light source.
The first button toggles the light on and off, as desired.
The third allows you to move the source around, with a little targeting
icon replacing your mouse
The second tho, that's more interesting.
The second button opens a debug menu for that light
There's a lot here, let's go through it.
Bit on the left is a list of templates, which allow you to sample
existing light types (No I have no idea why the background is fullwhite,
need to work on that pre merge)
You can choose one by clicking it, and hitting the upload button.
This replaces your existing lighting values with the template's,
alongside replacing its icon and icon state so it looks right.
There are three types as of now, mostly for categorization. Bar, which
are the larger typically stronger lights, Bulb, which are well, bulbs,
and Misc which could be expanded, but currently just contains floor
lights.
Alongside that you can manually edit the power, range, color and angle
of the focused light.
I also have support for changing the direction of the light source,
since anything that uses directional lighting would also tie light dir
to it.
This isn't *always* done tho, so I should maybe find a way to edit light
dir too.
My hope is this tool will allow for better concepting of a room's
lights, and easier changing of individual object's light values to suit
the right visuals.
### Lemon No Why What
Ok so I applied angle lights to bars and bulbs, which means I am
changing the lighting of pretty much every map in the codebase.
I'm gonna uh, go check my work.
Alongside this I intend to give lighting some depth. So if there's room
to make a space warmer, or highlight light colors from other sources, I
will do that.
(Images as examples)
I also want to work on that other goal of mine, making breaking lights
matter. So I'll be doing what I can to ensure you only need to break one
light to make a meaningful change in the scene.
This is semi complicated by one light source not ever actually reaching
fullbright on its own, but we do what we must because we can.
I'm as I hope you know biased towards darker spaces, I think contrast
has vibes.
In particular I do not think strong lights really suit maintenance.
Most of what is used there are bulbs, so I'm planning on replacing most
uses with low power bulbs, to keep light impacts to rooms, alongside
reducing the amount of lights placed in the main tunnels
**If you take issue with this methodology please do so NOW**, I don't
want to have to do another pass over things.
Oh also I'm saving station maps for last since ruins are less likely to
get touched in mapping march and all.
### Misc + Finishing Thoughts
Light templates support mirroring vars off typepaths using a subtype,
which means all the templates added here do not require updating if the
source type changes somehow. I'd like to expand the template list at
some point, perhaps in future.
I've opened this as a draft to make my intentions to make my changes to
lights known, and to serve as motivation for all the map changes I need
to do.
### Farish Future
I'm unhappy with how we currently configure lights. I would like a
system that more directly matches the idea of drawing falloff curves,
along with allowing for different falloffs for different colors,
alongside extending the idea to angle falloff.
This would make out of engine lighting easier, allow for nicer looking
lights (red to pink, blue to purple, etc), and improve accessibility by
artists.
This is slightly far off, because I have other obligations and it's
kinda complicated, but I'd like to mention it cause it's one of my many
pipedreams.
## Changelog
🆑
add: Added angle lighting, applies it to most wall lights!
add: Adds a lighting prototyping tool, mappers go try it out (it's
locked behind the mapping verb)
/🆑
---------
Co-authored-by: MMMiracles <lolaccount1@ hotmail.com>
* [MDB IGNORE] Angled Lights & Lighting Prototyping Tool
* Update north_star.dmm
* Revert "Update north_star.dmm"
This reverts commit bb5b8b5a549f7edc3e23a369a147ed96bab41991.
* Updatepaths
* Update nukie_base.dmm
* Newer version of northstar with the penguins
* Update northstar_cryo.dmm
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: MMMiracles <lolaccount1@ hotmail.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* Terminals will be on the same layer as their APC/SMES by default & Selecting a layer when constructing an APC terminal now works. (#76784)
## About The Pull Request
Terminals built on APCs and SMES units using left click will now be on
the same layer as the machine they're being built for, instead of the
first layer.
They can still be built on other layers using right click and that
feature will now work for APCs, not just SMES units (it was seemingly
forgotten to actually use the argument of the make_terminal() function.)
## Why It's Good For The Game
It is far more intuitive this way, and makes building terminals
generally more convenient.
The fix in the case of APCs is good simply by virtue of being a fix.
## Changelog
🆑
qol: terminals built by left-clicking on SMES and APC units will now be
on the same layer as the machine.
fix: constructing a terminal on a specific layer with right-click now
works for APCs, not just SMES units
/🆑
* Terminals will be on the same layer as their APC/SMES by default & Selecting a layer when constructing an APC terminal now works.
---------
Co-authored-by: A miscellaneous Fern <80640114+FernandoJ8@users.noreply.github.com>
* [NO GBP] Minor Turbine Patches (#76713)
## About The Pull Request
If the turbine compressor input turf or the stator output turf was
destroyed while the turbine is running(say the turf was bombed or
deconstructed with an RCD) then the turbine would runtime as it would
attempt to dump gases on the deleted turf.
This fixes that.
Also adds a warning examine for the rotor if its parts are not
connected, to let you know if something is off which is useful when you
don't have the turbine computer to tell you that.
## Changelog
🆑
fix: turbine does not runtime when its input or output turf is destroyed
while its running
qol: add warning examine for rotor when its parts are not connected
/🆑
* [NO GBP] Minor Turbine Patches
---------
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
* Fixes a likely copy paste error in the APC update_icon_state() proc (#76904)
## About The Pull Request
https://github.com/tgstation/tgstation/pull/76788 introduced this.
I don't think it was intentional. Probably a copy paste error, which is
bound to happen when you clean so many files! My goodness.
Keep up the good work though @ YesterdaysPromise!!
## Why It's Good For The Game
Downstreams can have different filepaths for sprites, and this would
override them.
## Changelog
🆑
code: apc's update_icon_state proc will no longer set the icon file path
/🆑
* Fixes a likely copy paste error in the APC update_icon_state() proc
---------
Co-authored-by: Bloop <vinylspiders@gmail.com>
* Macros multi-z code, removes the false premise of manual offsets (#76248)
## 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
* modular files how very dare you
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Adds repair examine hints to the Gravgen (#76824)
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
Somebody told me recently "Hey, I beat the gravgen up and nothing would
fix it!"
Turns out there's actually really simple steps! Just absolutely no
in-game place to find them.
So, about 2 weeks after I said I would, I made less than 15 lines of
code.
Fixing any other horrifying things about the gravgen are out of my
control. I'm just capable of the examine lol
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
Knowing you can fix stuff is the first step to fixing it!
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
qol: in the event the Gravity Generator becomes damaged, examining the
main part will now give repair hints!
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
---------
Co-authored-by: Jacquerel <hnevard@ gmail.com>
* Adds repair examine hints to the Gravgen
---------
Co-authored-by: OrionTheFox <76465278+OrionTheFox@users.noreply.github.com>
Co-authored-by: Jacquerel <hnevard@ gmail.com>
* Machine list is now stored in SSmachines | Remove excessive use of global lists for specific machine types
* Resolve merge conflicts
* Modular adjustments
* destroy this double return on destroy
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
Co-authored-by: Giz <vinylspiders@gmail.com>
* Adds an extra malf AI ability: Remote emagging. Also tidies up emag code and coverts a lot of things to balloon alerts
* Update communications.dm
* Modular override
* Some modular adjustments, removes 'emagged' vars in favor of obj_flags
* whoops, mobs don't have obj_flags.
---------
Co-authored-by: nikothedude <59709059+nikothedude@users.noreply.github.com>
Co-authored-by: Giz <vinylspiders@gmail.com>
* Icon folder cleaning wave one
* Fixe a merge conflict
* Fixes some more merge conflicts
* Fixes some modular icon paths
* Fixes even more modular icon paths...
Hopefully that's the last of them
* Fixes some merge discrepencies
* More merge issues
* ok
* not ok
---------
Co-authored-by: YesterdaysPromise <122572637+YesterdaysPromise@users.noreply.github.com>
Co-authored-by: Giz <vinylspiders@gmail.com>
* Clarifies some silicon interactions via screentips, also converts some stuff to balloon alerts (#76690)
## About The Pull Request
APCs, fire alarms, and holopads now communicate a few more hotkeys for
interaction with silicons via examine. Ex. APCs now tell silicons they
can disable lighting with shift-click.
## Why It's Good For The Game
1. Balloon alerts are cool.
2. UX is also cool.
## Changelog
🆑
qol: APCs, fire alarms, and holopads now communicate some more of their
silicon interactions via screentips.
qol: APCs, fire alarms, holopads and turret control panels now use
balloon alerts for more of their notifications.
/🆑
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Clarifies some silicon interactions via screentips, also converts some stuff to balloon alerts
---------
Co-authored-by: nikothedude <59709059+nikothedude@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Power machines can now operate on different cable layers (#76075)
## About The Pull Request
Machines that require a cable underneath it to operate like Tesla, SMES,
Emitter & Turbine now look for the `cable_layer` (red, yellow, blue
default being yellow) to operate on and not `machine_layer`(that var is
removed). `machine_layer` & `cable layer` served the same purpose so i
removed `machine_ layer` var and made it just look for the cable layer
to operate on to reduce redundancy.
The following machine's can have their cable layer changed with a
multitool when in the specified state
1. Emitter when it's not welded
2. Tesla Coil when it's not wrenched
3. SMES when it does not have a terminal attached
3.1 Terminal of the SMES cable layer can also be changed with Right
Click during installation
4. APC terminal cable layer can also be changed with Right Click during
installation
5. Turbine rotor when its panel is open
Here all 3 SMES were on 3 separate layers of cable but they were all
joined by a single multi z layer hub cable summing up all their
contribution's even though they were on different cable layers.
## Why It's Good For The Game
It makes sense that a machine should only look for what cable layer it
should operate on and adding another layer called machine layer was just
redundant. Also cable layers blue & red which could not be used by
machines are now usable
## Changelog
🆑
fix: cable layers 1 & 3 can now be used by machine's like emitters,
smes, tesla coil & turbine.
fix: terminals(smes & apc) can operate on different cable layers by
installing them with right click
/🆑
---------
Co-authored-by: Time-Green <7501474+Time-Green@ users.noreply.github.com>
* Power machines can now operate on different cable layers
---------
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
Co-authored-by: Time-Green <7501474+Time-Green@ users.noreply.github.com>
Co-authored-by: Bloop <vinylspiders@gmail.com>
* Fixes the APC full_charge mapping helper (#76650)
## About The Pull Request
Currently the full_charge APC helper just sets the cell's charge to 100
flat, instead of 100%. This PR fixes that by setting the cell's charge
to whatever the cell's max charge is.
This is also my first PR. I was hoping to add a whiteship or something
instead but a fix is good too.
## Why It's Good For The Game
A mapping helper for giving APCs a full charge should actually fully
charge the APCs, instead of giving them only ~5% charge.
## Changelog
🆑
fix: Fully charged APCs will now actually be fully charged, instead of
nearly empty.
/🆑
* Fixes the APC full_charge mapping helper
---------
Co-authored-by: Nimowa <nimowa.kaido@protonmail.com>
* Fixes some stupid airlock sleeps
* Fixes the conflicts before checking the merge conflicts
* Converts another wires = to set_wires() and removes another issue
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Standardize Welder Fuel Usage (#76021)
Remove welder fuel usage from all actions except attacking and leaving
it on
most welder tasks require a minimum of 1u of fuel, some longer tasks
require a minimum of 2 or 3u welders now drain 1u every 5 seconds
they're active
## About The Pull Request
Prior to this PR welder fuel usage was random, a lot of tasks didn't use
any welder fuel and welders were basically near infinite so long as you
didn't use them for combat, it took 26 seconds of activity to drain 1u
of fuel, that means an emergency welder alone could run for 5 minutes
straight before needing a refuel
After this PR all welders will drain 1u every 5 seconds instead of every
26 seconds, but welding objects won't require extra fuel anymore, making
the fuel usage much more consistent.
resolves#55018
## Why It's Good For The Game
Actually makes fuel tanks useful and relevant without making it
obnoxious to do repetitive quick tasks like turn rods into plates,
there's actually a reason to upgrade off the emergency welder now since
it lasts 50 seconds rather than 5 minutes
## Changelog
🆑
qol: Welders now have a more consistent fuel usage
/🆑
* Standardize Welder Fuel Usage
---------
Co-authored-by: Couls <coul422@gmail.com>
* Ton of turbine patches (#75968)
## 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
/🆑
* Ton of turbine patches
---------
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
* Fixes iron duplication bug (This is why you use defines, people) (#76030)
## About The Pull Request
In PR #75437, sheets were changed from being 2000 units of material to
being only 100. This caused an unintended bug, as the datum for iron
rods didn't properly use the define. As a result, you could duplicate a
sheet of iron into 20 sheets by turning it into rods and inserting it
into a protolathe. This makes rods properly use the define, fixing the
dupe.
## Why It's Good For The Game
Dupe bugs bad, I guess.
## Changelog
🆑
fix: You can no longer duplicate iron by turning sheets into rods and
putting the rods back into the protolathe
/🆑
* Fixes iron duplication bug (This is why you use defines, people)
---------
Co-authored-by: GPeckman <gpeckman1@gmail.com>
* Light replacer & item patches (#75960)
## About The Pull Request
Somehow this code break's every week, hopefully this should be the last
1. Fixes#75951
It wasn't just a problem with Jani Borg light replacer but the normal
one's too. Now they all accept glass sheet's & light tubes (including
broken one's) when you attack them with a light replacer and not just
when you pick them up with hand (which Borg's can't do obviously) and
then clicking them on the light replacer.
2. Glass sheet's & shard can be put inside backpack's or other storage
item's and now they will all be consumed from the storage and not just
light tubes & bulbs
3. Make's feedback message's more informative and display them for all
insert event. they weren't displayed when a broken light tube was put in
the light replacer
4. Only glass shards are accepted by the light replacer and not plasma,
titanium shards etc. we should not use `istype()` for this purpose
5. Removed redundant` Initialize()` proc from `obj/item/light`
6. VV editing var's works properly
7. Blue beam for bluespace light replacer last's just 0.5 seconds so it
doesn't look awkward
## Changelog
🆑
fix: light replacer accepts glass sheets & light tubes when you attack
them with a light replacer
fix: only glass shards can fill the light replacer not other shard types
qol: glass sheet's & shards inside storage items like backpacks are also
consumed when you attack the light replacer with it
qol: feedback messages when inserting lights, glass sheet's, shards into
the light replacer are more descriptive and displayed for all insert
event's
qol: blue beam for bluespace light replacer last's just 0.5 seconds so
it doesn't look awkward
refactor: renamed `add_shards()` to just `add_shard()` for adding 1
shard at a time
refactor: removed redundant` Initialize()` proc from `obj/item/light`
refactor: VV editing var's works properly
/🆑
---------
Co-authored-by: Time-Green <timkoster1@ hotmail.com>
* Light replacer & item patches
---------
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
Co-authored-by: Time-Green <timkoster1@ hotmail.com>
* Allows field generators to contain explosions. (#75771)
## About The Pull Request
Allows field generators to contain explosions. The fields will not let
the explosion propagate past them.
## Why It's Good For The Game
Allows people to contain the tesla for fun, or on station bomb testing
if they so desire.
## Changelog
🆑
balance: Field generators can parry explosions.
/🆑
* Allows field generators to contain explosions.
---------
Co-authored-by: Pickle-Coding <58013024+Pickle-Coding@users.noreply.github.com>
SkyratBot
