## 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.
/🆑
Whatever you do, if it warrants the use of something like
`handle_atom_del`, chances are `Exited` can do it better, as most of
these cases involve movables that shouldn't be moved out of their loc
(`Destroy` forcefully moves movables to nullspace) without calling
specific procs, and for the remaining few, `handle_atom_del` doesn't
even cover the eventuality of a movable being deleted outside the source
atom, so it's quite garbage.
Beside, I feel confident in saying `handle_atom_del()` is older than the
DCS, an echo on the workarounds done at the time.
## About The Pull Request
Title.
Vendor tipping code is now on /atom/movable, and any movable can fall
over like a vendor does. Things like crits have been moved to
type-specific availability tables, their effects are now held in their
own proc, are now random per crushed item, have probability weights,
etc.
In the process of making this PR I also had to fix another issue, where
a bunch of take_damage() overrides had incorrect args, so that explains
the take_damage changes I made.
Tipping now also attacks any atoms on the target, given they use
integrity.
Adds 2 new malf modules.
1. REMOTE VENDOR TIPPING: A mid-cost and mid-supply module allows malf
AIs to remotely tip a vendor in any of the 8 directions. After 0.5
seconds of delay and a visual indicator (along with other warnings), the
vendor falls over.
1.1. In the process of making this I had to expand a arrow sprite to
have orthogonal directions, which is why you may see the testing dmi
being changed.
2. CORE ROLLING: A mid-cost but low-supply ability that allows the AI to
roll around and crush anything it falls on, including mobs. This has a
5% chance to have a critical hit so it isnt THAT terrible - plus it's
guaranteed to never stunlock. It's real utility lies in the fact the AI
now has limited movement without borgs. Also, the psychological factor.
As a bonus, vendor tipping now uses animate and transforms instead of
replacing matrices.
## Why It's Good For The Game
1. Generifying vendor tipping code is just good, period. It's a very
wacky and silly little piece of code that really doesn't need to be
isolated to vendors exclusively. ANY big and heavy object can fall over
and do a ton of damage.
1.1. Also, adding weights to critical hits is really good, because it
lets things like the headgib finally be a lot less terrifying, as
they're a lot less likely to happen.
2. Remote vendor tipping is a bit of a goofy ability that isn't really
THAT practical but has a chance of catching someone unaware and doing
some serious damage to that person alone.
2.1. Atop of this, vendor tipping isn't that loud of an action as say,
blowing things up, or doing a plasma flood. Even overrides aren't this
silent or a non-giveaway. A vendor falling on someone, though, is a
mundane thing that happens a lot. This is a decent way to assassinate
people before going loud (or at least, damage people) that isn't offered
yet.
4.
3.1. For real though, AIs rolling around is just fucking hilarious. The
ability to move isn't offered right now (which isn't that much of a bad
things), but with sufficiently limited charges (or limits to how many
times you can buy the ability), this can be a funny little t hing that
lets the AI potentially hide somewhere on the sat (or just relatively
close to the sat, such as engineering [it can't go through the
teleporter with this but it can go through transit tubes]) without the
need for borgs.
3.2. Also, it lets the AI sacrifically execute people by blowing up
their brains.
## 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.
/🆑
## 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
/🆑
## 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
/🆑
## About The Pull Request
Changes this code to be signalized on AI cards
76bddbd903/code/modules/mob/living/silicon/ai/death.dm (L44-L49)
Minor code improvements as well (Moving the sleep out from flushing into
its own async proc)
## Why It's Good For The Game
Cringe code
## Changelog
🆑 Melbert
code: AI cards should react more snap-ily to having their occupant
perish
/🆑
## About The Pull Request
Removes all of the duplicate global lists for specific machine types
where the only thing they do is store all machines of that type.
Adds machine tracking to SSmachines in the form of a list for all
machines, and then an associative list for machines by their type.
Previously we have machines in multiple global lists, such as airlocks
being in GLOB.doors, GLOB.airlocks, GLOB.machines.
This makes that not a thing, and also means that iterating through
GLOB.machines looking for a specific type is no longer as expensive.
## About The Pull Request
New malf AI upgrade
Remote safety overrides: Mid-cost, Mid-supply. Allows the AI to remotely
emag things it can see and can access.
1. Very useful for psychological warfare (Emagging APCs to throw the
crew off their trail)
2. Logically makes sense - why, of all things, can the AI not emag
anything when it's fundumentally integrated with the station's
electronics?
3. Generally speaking can only access things that make sense for it to
access - it cannot emag ethereals, sadly
In order for this to work, emag_act now returns a boolean, designating
if the emag had any effect.
While I was in there, I also added args to every single emag_act I could
find and added far more feedback/converted a lot of things to balloon
alerts to allow the AI to see if its emag had any effect.
## Why It's Good For The Game
It just makes sense that the AI, the most electronically-sensitive
entity in the game, would be able to emag things. Plus, more options
given to malf that aren't strictly MURDER KILL MURDER are always a plus,
especially if they allow for fancier plays.
## Changelog
🆑
add: New malf ability: Remote safety overrides. Allows the AI to
remotely emag things it has access to.
code: emag_act() now returns a boolean designating it's success in
emagging
code: All instances of emag_act() now have the proper arguments
qol: Most usecases of emagging now have some kind of feedback, and
existing feedback has been sanity checked and converted to balloon
alerts.
/🆑
## About The Pull Request
Further continous organizing and cleaning the Icons folder. There are
still some minior nitpicks left to do, but I reached my daily sanity
expenses limit again, and the faster these get in the less issues for
both me and others later. Also cleans some mess I caused by my blindness
last PR.
## Why It's Good For The Game
Saner spriters = better sprites
## 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>
## 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.
/🆑
## About The Pull Request
This adds a few hotkeys to APCs for AIs and borgs.
- Toggle environmental (ctrl + shift)
- Toggle lighting (shift)
- Toggle equipment (alt)
- Toggle breaker (ctrl)
These are included as contextual screentips. Also removed the UI popup
when using RMB to toggle the lock as well since it was annoying. Went
and cleaned up quite a bit of one letter var names and `usr` arguments.
## Why It's Good For The Game
Easier controls for equipment.
## Changelog
🆑
qol: Add hotkeys to APCs for AIs and borgs. Toggle environmental (ctrl +
shift), toggle lighting (shift), toggle equipment (alt), and toggle
breaker (ctrl).
qol: Remove APC UI popup when using RMB to toggle the lock.
/🆑
---------
Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com>
## 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>
Remove welder fuel usage from all actions except attacking and leaving
it on
most welder tasks require a minimum of 1u of fuel, some longer tasks
require a minimum of 2 or 3u welders now drain 1u every 5 seconds
they're active
## About The Pull Request
Prior to this PR welder fuel usage was random, a lot of tasks didn't use
any welder fuel and welders were basically near infinite so long as you
didn't use them for combat, it took 26 seconds of activity to drain 1u
of fuel, that means an emergency welder alone could run for 5 minutes
straight before needing a refuel
After this PR all welders will drain 1u every 5 seconds instead of every
26 seconds, but welding objects won't require extra fuel anymore, making
the fuel usage much more consistent.
resolves#55018
## Why It's Good For The Game
Actually makes fuel tanks useful and relevant without making it
obnoxious to do repetitive quick tasks like turn rods into plates,
there's actually a reason to upgrade off the emergency welder now since
it lasts 50 seconds rather than 5 minutes
## Changelog
🆑
qol: Welders now have a more consistent fuel usage
/🆑
## About The Pull Request
[A common problem with explosions is an overabundance of
sleeping](6499077a09)
In an attempt to solve this issue, let's not continue to sleep and do
work in door closing if the door is already deleted
(This is caused by firelocks activating due to other adjacent objects
deleting, triggering an atmos update, and closing the firelocks before
they get bombed. I don't have a elegant way of resolving that core
problem, so let's just minimize the impact)
[Nukes a stupid sleep loop in airlock
code](5b16360520)
When an airlock was depowered, it would enter a sleep loop, decrementing
its delay by 1 second every well, one second, so long as it had the
right wires flipped
This is very stupid
Instead, let's use signals off wire changes and a combo of timer and
remaining time var to do this with JUST a timer
Most of the changes here are just swapping over wires to a setter to
make signal registration work\
## Why It's Good For The Game
Less sleeping around explosions means less dropped ticks after a bomb
goes off. Good just in general
Also this excises dumb boomer code and adds some hooks for other devs to
use (we should use wires more man)
You can now weld an unbroken but damaged Apc cover in order to repair
its integrity.
If an Apc cover is broken you can crowbar it off and replace it with a
new one using an Apc frame (but you'll need to weld its integrity back
up to reinforce the haphazard connections you've made)
I also went ahead and added comments to some of the code because Apc
code is a little daunting.
Firealarms & Airalarms `deconstruct()` procs are wrong, they spew out
electronics & cable regardless of what build stage their on
Fire alarms providing free electronics & cable without even installing
them
https://user-images.githubusercontent.com/110812394/233784785-650fbd64-3c6c-44c8-b377-c3a8244d28ac.mp4
Air alarms providing free electronics & cable without even installing
them
https://user-images.githubusercontent.com/110812394/233784799-cdd38967-8a59-454d-8da4-1360d03ff12c.mp4
Bug exploits now come to an end
Also fixes balloon alerts run timing when cutting terminals connected to
apc's/smes etc. because the atom gets deleted, by the time the balloon
alert gets executed it adds a timer on the deleted object causing
runtimes.
## Changelog
🆑
fix: air alarms correctly spew out cable & electronics depending on
their build stage when their integrity reaches 0 i.e. destroyed
fix: fire alarms correctly spew out cable & electronics depending on
their build stage when their integrity reaches 0 i.e. destroyed
fix: balloon alerts runtiming when cutting terminals
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
I asked someone in discord if it was worth it, they said it was, from
what i remember at least.
## Why It's Good For The Game
More comfort with apc's for mappers.
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Refactors regenerate organs to be slightly more intelligent in handling
organ changes and replacements.
Noteably:
- We don't remove organs that were modified by the owner; such as
changing out your heart for a cybernetic
- We early break out of the for loop if they aren't supposed to have an
organ there and remove it
- We check for the organ already being correct, and just healing it and
continuing if it is
Also changes the names of some of the organ helpers into snake_case
### Mapping March
Ckey to receive rewards: N/A
## Why It's Good For The Game
## Changelog
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
## About The Pull Request
1. Fixes#70430
- APC's
- Air Alarms
- Fire Alarms
- Vents
- Scrubbers
Now all re-assign themselves to their correct areas & properly rename
themselves after an area has been created, modified via the station
blueprints.
2. Now Area's can't be expanded if both the current area where the
player is standing and the selected area both have an apc because that
would make the final area have 2 apc's
3. When 2 areas are merged, If the old area has no more turfs left then
it is deleted
4. Bonus fixes
- is removed redundant `Initialize()` proc inside light switch.
- arcd has all upgrades installed
## Changelog
🆑
fix: area machinery from breaking after creating & modifying areas via
the station blueprints.
refactor: turfs are cannonized from areas during creation/editing
operations & empty areas are deleted
refactor: removed duplicate Initialize() from light switch
refactor: arcd has all upgrades installed
/🆑
This builds on what #69790 did and improved the code even further.
Notable things:
- `Topic()` is a deprecated proc in our codebase (replaced with
Javascript tgui) so it makes sense to rename `canUseTopic` to
`can_perform_action` which is more straightforward in what it does.
- Positional and named arguments have been converted into a easier to
use `action_bitflag`
- The bitflags adds some new checks you can use like: `NEED_GRAVITY |
NEED_LITERACY | NEED_LIGHT` when you want to perform an action.
- Redundant, duplicate, or dead code has been removed.
- Fixes several runtimes where `canUseTopic` was being called without a
proper target (IV drips, gibber, food processor)
- Better documentation for the proc and bitflags with examples
## About The Pull Request
APC was assigned a name before it was assigned an area causing null
names.
Another bug i noticed was that newly built apcs were also not assigned
names. Thats fixed now too
Fixes#73052
## Changelog
🆑
fix: apc not assigning itself a name based on its area
fix: newly built apc's not getting assigned area names
/🆑
## About The Pull Request
Adds some more stuff you can build with the RCD
1. Under structures you can now build/deconstruct catwalks & construct
Reflector Frames. Destorying a catwalk will cut any cable on it leaving
pieces of it behind
2. If you have the frames upgrade you can construct APC, Air Alarm &
Fire Alarm frames on walls & Flood light fixtures[fully wired]. It only
creates the wall mount and sticks it on the wall. Wiring, Circuits and
finishing the frame is still your job
3. If you have the furnishing upgrade you can create racks & beds &
additional bar stool
**Important Code Refractors**
1. `/turf/closed/wall/proc/try_wallmount()` will return true only after
you have successfully mounted the wallframe or stuck an poster on it &
not simply check if you are trying to mount a valid thing on it
2. `apc_tool_act/rcd_act()` was incorrectly checking passed_mode for the
simple circuit upgrade and not the `the_rcd.upgrade `flag. Thats fixed
now to
3. newly created APC's weren't assigning themselves to their areas
allowing multiple to be created in one area. Thats fixed now
4. Walls, Airlocks & other stuff could be built on tiles having
something dense that would block it. For example a wall could be build
on top of a machine frame!!. Thats also fixed now
## Why It's Good For The Game
More stuff you can build rapidly with the RCD
## Changelog
🆑
add: more designs for the rcd
refactor:` try_wallmount()` to return true only after successful mount
fix: `apc_tool_act/rcd_act()` incorrecly checking for simple circuits
upgrade in the wrong variable
fix: newly created APC's not assigning themselves to their areas.
fix: rcd building structures [walls, airlocks etc] on turf's that
already have structures on them
/🆑
## About The Pull Request
And makes some improvements on their balloon alerts.
The code has a lot of if/else nonsense, I followed how other big chains
of screen tips work now but maybe it can be smoothed out, I put the code
on it's own DM so we don't need to stare at that wall while dealing with
other APC code.
## Why It's Good For The Game
APC is definitely the worst offender on construction being a mess.
I personally like that it is a complicated machine that needs multiple
pieces to build/repair, but the bad user experience of doing that just
can't be excused.
Need to memorize multiple steps, a sequence of tools, you have "traps"
you can get caught into by using the wrong tool, using crowbar at the
wrong time and locking the access cover or engiborgs using a screwdriver
and ejecting the cell as examples.
Now you will know what will happen before you misuse tool and you will
get hints about what each tool does to the APC, even if it is not the
right step at the moment, as a balloon alert will explain why the
attempt failed.
## Changelog
🆑 Guillaume Prata
qol: APCs have contextual screen tips now.
/🆑
## About The Pull Request
Part of a prior PR that was closed (#72562). This version does not add
the check in CI.
## Why It's Good For The Game
The work is already done, so I figured why not.
## Changelog
N/A Nothing player facing
Co-authored-by: Jeremiah Snow <jlsnow301@pm.me>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Adds lints for `balloon_alert(span_xxx(...))` (which is always wrong),
and balloon alert where the first letter is a capital (which is usually
wrong). Fixes everything that failed them. As a reminder, abbreviations
like "AI" and "GPS" shouldn't be capitalized in a balloon alert.
In cases where this is intentional for flavor (there was one case), you
can `UNLINT` like so:
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
## About The Pull Request
[Saves 0.2 seconds of init time. 50% of emissive
blockers](8318b648f6)
Emissive blockers are a decent expense during init, even these, which
are the ones that update outside of initialize.
I've inlined them, removed some redundant vars and checks, reduced the
arg count, and shifted some things around. This ends up saving 200ms, or
50% of its total cost.
I also shifted mutable_appearance about a bit. it's not a massive
saving, but it is technically faster
[Prevents a few redundant appearance_updates, saves 0.8 seconds of
init](5475cd778b)
Prequisit info: update_appearance is decently expensive
It's good then to only do it if we have a reason to, right?
Me and moth were shooting the shit about just general init time, and we
came up with the idea of tracking which update_appearances actually
"worked" and which didn't.
That bit comes later, let's enjoy the fruits of that work first
First, holograms were calling update_appearance on process, for almost
no reason.
I patched the one event they don't already "react" to, and then locked
it behind a change decection if.
good for live, doesn't impact init.
Next, decals. If you add a decal to something before it inits, it'll
react to the after successful init signal.
The trouble is the same atom could have its appearance updated from this
MORE then once, since decals can be stacked on tiles, and signal
unregisters don't work once the signal is sent.
So we add a flag to track if we've had this happen to us or not, so it
only happens once.
saves 80 ms
Power! lots of things call power_change on init, often more then once.
We'll update appearance for each of those calls, even if only one is an
actual change.
That's silly, better to track what sort of power we're using for our
appearance and go off that changing
This was taking about 300ms. Really stupid
Icon smoothing. After emissive blockers were added, any change to
something's icon smoothing would lead to an update_appearance call.
Nasty shit, specially cause of walls, which don't even use emissive
blockers.
Ok then, so we'll always update appearance for movables, and will allow
turfs that are interested to hook it manually.
Not many of those anyhow
This is slightly a dev ux thing, but it saves 600ms so I think it's
worth it. Rare case anyway
Telecomms:
telecomm machines were updating appearance on process. This is to cover
for them turning on/off on process.
Better then to just check if on actually changed.
This cost adds up midgame, doesn't impact init tho
Materials:
There's this update_appearance call in material on_apply. it doesn't do
anything.
The logs will lie to you and say it does, but it's just like reapplying
emissives. It doesn't need to exist
Saves like 50ms
Canisters:
Live thing, lots of time wasted updating appearance for no reason, lets
see if we change anything first yes?
[Uses defines to wrap update_appearance for
tracking](4fa82e1c9d)
[Undoes _update_appearance changes, instead reccomends 2 regexes to
use](a8c8fec57a)
I need file and line number for my tracking, so I need to override
update_appearance calls, and also preferably not require every override
of update_appearance to handle dummy file + line args.
So instead, I created a wrapper proc that checks to see if appearanaces
match (they're unique remember, the two of the same visual appearance
will be equivalent)
The trouble is I can't intercept JUST proc calls, or JUST function
definitions with defines. it needs to be both.
So I renamed the /update_appearance proc to /_update_appearance
this way I can capture old uses, and don't need to worry about merge/dev
brain skew
~~It does mean that all update_appearance proc definitions now look
weird tho.
My profiling is leaking into dev ux. I wish I had better templating.~~
**The above is no longer being pr'd**, it's instead just recommended via
a few regexes adjacent to the define.
Smelled wrong anyhow
[Adds a setter for panel_open, so I can update_appearance on
it](cf1df8a69f)
## Why It's Good For The Game
Speed
## About The Pull Request
Makes a number of changes to the Grey Tide event, some of which are and
some of which aren't player facing.
Player facing bits:
- The lights will once again turn off when the event ends and the doors
begin opening. Originally, the lights would all shatter when the event
hit, providing a cover of darkness for opportunists to sneak around
under. Unfortunately this would prevent the AI from fixing the doors
until the lights were replaced, leading to headaches and the removal of
this functionality in #43159. Now, the lights are simply turned off at
the APC instead of shattered.
- The lights now flicker at certain intervals as the event is running,
rather than just right at the start.
- Announcement has been slightly modified to indicate that the event
hits more than just airlocks.
- Event runs way faster. Doors open all at once, rather than
one-at-a-time.
And now for the non player-facing bits:
- The filename is now grey_tide.dm instead of prison_break.dm. The event
was effectively re-branded to the Grey Tide event six years ago, but the
filename was unchaged.
- potential_areas is now a part of setup instead of a var on the
round_event.
- Cleans up instances of single-character varnames and stuff not in
snake case.
- The event now checks if it has any valid areas (will it work or not)
at the start, rather than at the end.
- The event now sends a global signal when run, rather than checking
everything in the entire world. It should run faster now.
- Everything that can be affected by the grey tide event now stores its
functionality on a signal handler, including the light flickers
## Why It's Good For The Game
Makes the grey tide event a bit more interesting and easier to take
advantage of. Cleans up the backend code a bit.
## Changelog
🆑 Rhials
balance: The lights will now flicker more frequently before a Grey Tide
event
balance: The lights will now be shut off via the APC when the Grey Tide
event opens up a department.
code: Makes some miscellaneous code improvements to the Grey Tide event
code: Grey tide event runs much faster
code: Renames prison_break.dm to grey_tide.dm
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
Hey there,
Space Ruins all use the same name "Unexplored Location", and one of them
is conflicting:
I have no fucking idea which one this is though, given that I took this
screenshot a week ago. It doesn't fail unit tests since it's on a space
ruins Z-Level, which are exempt from those checks. So, let's just at
least put the type in the message so someone can figure it out sooner.
## Why It's Good For The Game
We shouldn't be having duplicate APCs, and this problem is very hard to
fix right now. At least if I had a type, I would be much more able to
tell which subtype of `/area/ruin/space` is fluking on us.
## Changelog
Nothing that affects players.
So i left over some basic `/whatever/proc/format` uses in the original
PR this fixes it.
Notable exceptions to the rule:
- Paths in add_verb/remove_verb, we need full path instead of a name
there to access verb metadata so we can't use proc ref macros there.
- regex.Replace, found out that it does not accept call by name. Instead
i added new REGEX_REPLACE_HANDLER so we can at least try to mark these.
There's still leftover global procs that do not use GLOBAL_PROC_REF but
they functionally equivalent so that's for later.
I don't see any reasonable way to grep for this. But if you got any
ideas please share.
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Fixes Unreadable APC Balloon Alerts as Ethereals
Hey there,
So basically, when an ethereal on combat mode would try and discharge an APC, they would get this, which is completely unreadable:
So, let's add a small sleep at the end of `togglelock()` for ethereals, and then proceed to continue on with the proc chain of whatever an ethereal might want to do with an APC.
* swaps the balloon alerts to add timers
less elegant, but it does do the job nicely
About The Pull Request
I've reworked multiz. This was done because our current implementation of multiz flattens planes down into just the openspace plane. This breaks any effects we attach to plane masters (including lighting), but it also totally kills the SIDE_MAP map format, which we NEED for wallening (A major 3/4ths resprite of all wall and wall adjacent things, making them more then one tile high. Without sidemap we would be unable to display things both in from of and behind objects on map. Stupid.)
This required MASSIVE changes. Both to all uses of the plane var for reasons I'll discuss later, and to a ton of different systems that interact with rendering.
I'll do my best to keep this compact, but there's only so much I can do. Sorry brother.
Core idea
OK: first thing.
vis_contents as it works now squishes the planes of everything inside it down into the plane of the vis_loc.
This is bad. But how to do better?
It's trivially easy to make copies of our existing plane masters but offset, and relay them to the bottom of the plane above. Not a problem. The issue is how to get the actual atoms on the map to "land" on them properly.
We could use FLOAT_PLANE to offset planes based off how they're being seen, in theory this would allow us to create lens for how objects are viewed.
But that's not a stable thing to do, because properly "landing" a plane on a desired plane master would require taking into account every bit of how it's being seen, would inherently break this effect.
Ok so we need to manually edit planes based off "z layer" (IE: what layer of a z stack are you on).
That's the key conceit of this pr. Implementing the plane cube, and ensuring planes are always offset properly.
Everything else is just gravy.
About the Plane Cube
Each plane master (except ones that opt out) is copied down by some constant value equal to the max absolute change between the first and the last plane.
We do this based off the max z stack size detected by SSmapping. This is also where updates come from, and where all our updating logic will live.
As mentioned, plane masters can choose to opt out of being mirrored down. In this case, anything that interacts with them assuming that they'll be offset will instead just get back the valid plane value. This works for render targets too, since I had to work them into the system as well.
Plane masters can also be temporarily hidden from the client's screen. This is done as an attempt at optimization, and applies to anything used in niche cases, or planes only used if there's a z layer below you.
About Plane Master Groups
BYOND supports having different "maps" on screen at once (IE: groups of items/turfs/etc)
Plane masters cannot cover 2 maps at once, since their location is determined by their screen_loc.
So we need to maintain a mirror of each plane for every map we have open.
This was quite messy, so I've refactored it (and maps too) to be a bit more modular.
Rather then storing a list of plane masters, we store a list of plane master group datums.
Each datum is in charge of the plane masters for its particular map, both creating them, and managing them.
Like I mentioned, I also refactored map views. Adding a new mapview is now as simple as newing a /atom/movable/screen/map_view, calling generate_view with the appropriate map id, setting things you want to display in its vis_contents, and then calling display_to on it, passing in the mob to show ourselves to.
Much better then the hardcoded pattern we used to use. So much duplicated code man.
Oh and plane master controllers, that system we have that allows for applying filters to sets of plane masters? I've made it use lookups on plane master groups now, rather then hanging references to all impacted planes. This makes logic easier, and prevents the need to manage references and update the controllers.
image
In addition, I've added a debug ui for plane masters.
It allows you to view all of your own plane masters and short descriptions of what they do, alongside tools for editing them and their relays.
It ALSO supports editing someone elses plane masters, AND it supports (in a very fragile and incomplete manner) viewing literally through someone else's eyes, including their plane masters. This is very useful, because it means you can debug "hey my X is yorked" issues yourself, on live.
In order to accomplish this I have needed to add setters for an ungodly amount of visual impacting vars. Sight flags, eye, see_invis, see_in_dark, etc.
It also comes with an info dump about the ui, and plane masters/relays in general.
Sort of on that note. I've documented everything I know that's niche/useful about our visual effects and rendering system. My hope is this will serve to bring people up to speed on what can be done more quickly, alongside making my sin here less horrible.
See https://github.com/LemonInTheDark/tgstation/blob/multiz-hell/.github/guides/VISUALS.md.
"Landing" planes
Ok so I've explained the backend, but how do we actually land planes properly?
Most of the time this is really simple. When a plane var is set, we need to provide some spokesperson for the appearance's z level. We can use this to derive their z layer, and thus what offset to use.
This is just a lot of gruntwork, but it's occasionally more complex.
Sometimes we need to cache a list of z layer -> effect, and then use that.
Also a LOT of updating on z move. So much z move shit.
Oh. and in order to make byond darkness work properly, I needed to add SEE_BLACKNESS to all sight flags.
This draws darkness to plane 0, which means I'm able to relay it around and draw it on different z layers as is possible. fun darkness ripple effects incoming someday
I also need to update mob overlays on move.
I do this by realiizing their appearances, mutating their plane, and then readding the overlay in the correct order.
The cost of this is currently 3N. I'm convinced this could be improved, but I've not got to it yet.
It can also occasionally cause overlays to corrupt. This is fixed by laying a protective ward of overlays.Copy in the sand, but that spell makes the compiler confused, so I'll have to bully lummy about fixing it at some point.
Behavior changes
We've had to give up on the already broken gateway "see through" effect. Won't work without managing gateway plane masters or something stupid. Not worth it.
So instead we display the other side as a ui element. It's worse, but not that bad.
Because vis_contents no longer flattens planes (most of the time), some uses of it now have interesting behavior.
The main thing that comes to mind is alert popups that display mobs. They can impact the lighting plane.
I don't really care, but it should be fixable, I think, given elbow grease.
Ah and I've cleaned up layers and plane defines to make them a bit easier to read/reason about, at least I think.
Why It's Good For The Game
<visual candy>
Fixes#65800Fixes#68461
Changelog
cl
refactor: Refactored... well a lot really. Map views, anything to do with planes, multiz, a shit ton of rendering stuff. Basically if you see anything off visually report it
admin: VV a mob, and hit View/Edit Planes in the dropdown to steal their view, and modify it as you like. You can do the same to yourself using the Edit/Debug Planes verb
/cl
About The Pull Request
bgug fix stuff
APC controller UI has its elements section'ed off. The backend has been redone to make the behaviour of the APC controller a bit less janky. The console should be more stable, and all the soul has been removed from the code and the UI.
before this PR stales out from nobody wanting to review my pr, I should probably outline what exactly changed:
APC controller consoles have had their APC code almost entirely reworked. They no longer have to hold a reference to the person using the controller currently, and APCs themselves no longer hold a reference to the controller, instead to the person directly. A lot of code was moved to APC themselves to make it a lot more stable.
APC controller used to call toggle_breaker without passing args, causing a runtime. Fixed in
Fixes the power flow control console not actually being able to toggle breakers #69343
APC controller UI has had the Window.Content tags moved up to the top component, and a lot has been sectioned off to make the UI more sane.
AmpCheck used to look for a wire on it's turf, or as a fallback look for the Area APC. A check to see if the APC has a terminal did so on a weakref, causing a runtime and preventing the program from ever finding a valid APC in it's area, making it show nothing. This has been fixed. On the other hand, the power monitor console did not store the ground wire or APC terminal as a weakref, this has been updated. As a fallback, if there are still no APCs in the powernet, the UI will show a dimmer popup.
There was a "secret" power monitor variation in code so PDAs could not access monitors in hidden places. With the removal of PDAs, this control console is useless.
Why It's Good For The Game
Tiny bit of (much needed) polish on some useful tools in the engineering department.
Changelog
cl
fix: Fixed runtime when using AmpCheck without connecting the console with a wire.
fix: Fixed a few runtimes that could occur when using APC controller consoles.
qol: Sucked soul out of APC controller code and UI.
del: Removed "secret" power monitor console.
/cl
Doing some mapping work downstream and I noticed there were both directional and non directional high caps. Code dived to figure out which was the valid one to use and found the directional high caps were not actually inheriting the upgraded power cells do to bad name structure. Corrected inheritance structure. Updated Kilo and Icebox to use directional high caps as standard and updated several ruin and gateway missions to standard directional high caps
About The Pull Request
replaces a ton of log_game with user.log_message so the log is added to individual and global logs.
adds a few logs for individual LOG_VICTIM, LOG_ATTACK etc logging.
adds logging for bluespace launchpad's tele coords being changed.
took the word "has" out of log_combat, as it's extra and just lengthens the log.
Why It's Good For The Admins
It's extremely laggy to open game.txt so an alternative is individual game logs
Changelog
cl
admin: A lot of game logs will now also be in individual game logs, for convenience in log diving.
admin: Added logging for bluespace launchpad x and y offset changes, which go to individual game logs.
admin: Attack logs will now be slightly shorter, one useless word was removed.
/cl
Changes the to_chat messages from building/repairing/deconstruction/etherealing APCs to balloon alerts.
I tried to standardize the multiple names that some items get into one, example: control board or electronics into just board.
Renamed other things just to be cleaner on what tools to use, example: power terminal was change to cable terminal.
And added ! at the end of all error messages so it is easier to know that your attempt failed.
This PR rewrites almost all messages related to cascade events. Some messages felt kinda clunky to read or could have been written better. Overall, the new messages add to the experience as a cascade being a terrifying event in a way that I felt the old ones missed, and they make the event feel overall a lot sharper.
While looking at the resonance cascade code, I noticed that there a lot of stuff about cascades in the air which was not touched on. So, as I do, this PR evolved into a polish and roundup PR for cascades. There was a lot of stuff still hanging out relating to the event, and although the big backend of it sits, there was still a bit left to be completed. Therefore this PR deserves more the title of the "Resonance cascade POLISHENING" instead of the "REFLAVAHRING". But yeah, you ever go on a massive tangent before?
* Fuck you (refactors ur tails)
* Errors
* Wow. Pain.
* Fixes up probably everything
* finish up here
* Fixes hard del maybe
* original owner hard del
* garbage collection runtime
* suck my peen byond
* Mapped tails
* motherfucker.
* motherrfucker. again.
* Whooopppppsie
* yeah bad idea
* Turns out external organs literally just sat in nullspace forever if their parent was deleted, and didnt Remove() themselves, causing harddels.
* So anyways I repathed all organs
* Fixes
* really.
* unit test... test
* unit test-test but it passes linters this time because im a moh-ron
* I've lost track of what im doing at this point
* Hopefully fixes hard del?
* meh
* Update code/datums/dna.dm
* things n stuff
* repath from master pull
