## About The Pull Request
Per #90473, for some reason boulder breaking is right click exclusive
for items. Basicmobs also break boulders on left click, but the tooltip
claims they should use right click for it. Also cleaned up some related
code.
## Why It's Good For The Game
Doesn't really make sense to use exclusively right click for boulder
breaking, this can confuse newer players.
## Changelog
🆑
qol: Moved manual boulder breaking with tools to LMB, corrected boulder
tooltips suggesting incorrect mouse buttons for basicmobs.
/🆑
## About The Pull Request
Certain mobs, like bots, delete on death. Also fixed an incorrect
deletion check in crematorium code.
## Changelog
🆑
fix: Fixed certain mobs runtiming when dusted
/🆑
## About The Pull Request
This PR introduces the `set_locked()` proc, which I'll also need for
something else later.
## Why It's Good For The Game
I could still interact with the storage of a box I placed into a secure
safe after I locked the latter.
## Changelog
🆑
fix: Locking a storage item now locks you out of other storage items
inside it.
/🆑
## About The Pull Request
Handcuffed people can be buckled to the tram rails.
If the tram hits them then they will die badly.
If they're not shockproof and are buckled to a powered rail, it will zap
them repeatedly for a little bit of damage (but not a lot because you
probably want them to die from something else).
Unbuckling someone from a powered rail is also pretty dangerous.
While doing this I fucked around a bit with how the "is the tram deadly"
calculation worked because I didn't like how a deadly tram cuts your
head off but does literally no other damage. Now it pulverises _and_
beheads you.
## Why It's Good For The Game
Multiple people I spoke to believed this was already possible
## Changelog
🆑
add: Handcuffed people can now be tied to the tram rails
balance: tram rails will no longer electrocute you if they're not
powered
/🆑
---------
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
## About The Pull Request
This won't actually do anything on live, since those are all set to
UTC±0 currently
Pins logging and IC uses of time2text to UTC±0 instead of using the
system timezone (byond default)
Timezones not being set to utc0 caused issues before (and is again)
All timezones are now passed explicitly to make it more likely it's
cargo culted properly at least
Deletes worldtime2text cus it was gameTimestamp default args
## Why It's Good For The Game
Server timezone changes probably shouldn't affect logging, round times,
file hashes, IC time, when you caught fish, etc
## Changelog
🆑
refactor: Logging and IC timestamps will now always use UTC±0 and not be
affected by server system timezone changes
fix: Station and round times will not longer be incorrect if the system
timezone is not UTC±0
/🆑
---------
Co-authored-by: TiviPlus <572233640+TiviPlus@users.noreply.com>
## About The Pull Request
Reverts the storage initialization refactor and all subsequent related
PRs.
The original PR is below our standards both for code quality and
testing, and is majorly flawed at its core. This has been discussed with
other maintainers and headcoder(s?) over on discord. A lot of changes
from the PR could be brought over later, but in its current state it
should not have been merged.
- Closes#90322
- Closes#90313
- Closes#90315
- Closes#90320
- Closes#90312
- Closes#90344
## Why It's Good For The Game
This PR causes a series of major issues which cannot be resolved without
either completely rewriting a lot of the original PR, or bad code.
Not matching our standards is grounds for not merging a PR, and the fact
that a PR should not have been merged is a reason for a revert.
## Changelog
🆑
fix: Fixed a series of storage-related bugs caused by a refactor PR.
/🆑
## About The Pull Request
Fixes tram info plate from being underneath the tram wall, converting it
from a plaque to a sign.
## Why It's Good For The Game
Fix layering issue
## Changelog
🆑 LT3
fix: Tram information plate and other signs mount correctly on tram
walls
/🆑
## About The Pull Request
this fixes a bunch of code incorrectly calling qdel directly on a list,
and adds a stack trace to qdel if someone does pass a list to it
## Why It's Good For The Game
because I'm pretty sure qdel ends up calling fucking `del()` as `/list`
is not a `/datum`
## Changelog
No user-facing changes.
## About The Pull Request
Retypes the object, attaches it to the crate as a vis_overlay, and gives
it the correct vis_flag to share the plane.
This also means it now layers correctly on multiz, when previously it
would show up on the lowest level.
## Why It's Good For The Game
/obj/ is not meant to be bloated with stuff that can easily be an
effect. Also fixes a bug
## Changelog
🆑
fix: Mystery box items no longer layer on the lowest z_level when in
multiz
code: mystery_box_item is now a type of /obj/effect/abstract
/🆑
## About The Pull Request
516 requires float layered overlays to be using pixel_w and pixel_z
instead of pixel_x and pixel_y respectively, unless we want
visual/layering errors. This makes sense, as w,z are for visual effects
only. Sadly seems we were not entirely consistent in this, and many
things seem to have been using x,y incorrectly.
This hopefully fixes that, and thus also fixes layering issues. Complete
1:1 compatibility not guaranteed.
I did the lazy way suggested to me by SmArtKar to speed it up (Runtiming
inside apply_overlays), and this is still included in the PR to flash
out possible issues in a TM (Plus I will need someone to grep the
runtimes for me after the TM period to make sure nothing was missed).
After this is done I'll remove all these extra checks.
Lints will probably be failing for a bit, got to wait for [this
update](4b77cd487d)
to them to make it into release. Or just unlint the lines, though that's
probably gonna produce code debt
## Why It's Good For The Game
Fixes this massive 516 mess, hopefully.
closes#90281
## Changelog
🆑
refactor: Changed many of our use cases for pixel_x and pixel_y
correctly into pixel_w and pixel_z, fixing layering issues in the
process.
/🆑
---------
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
Co-authored-by: SmArtKar <master.of.bagets@gmail.com>
## About The Pull Request
This updates door remote accesses to match the accesses of their owner
-- research remote = RD access, and so on. However, the Captain's door
remote does not inherit this increased access, and is still relegated to
command areas like the bridge, AI upload, etc.
As well, it implements a logic for a given "domain" per remote holder,
based on high-security areas that are iconic of the given role. As such,
even though they may have access to the Vault, no other Head besides the
Captain can open the Vault with their remote, the head remotes (beside
security) can't open the brig (Captain didn't have access anyway), and
so on. The restricted areas and the remote with authority to open that
area are as follows:
**Captain**
- The whole station
- Note: Still restricted by the remote access, which is: Bridge, Vault,
AI Upload, Teleporter, Gateway, Captain's Office, EVA
Head of Personnel
- Gets no special "domain" for their remote, but otherwise receives
HoP's round-start access
Head of Security
- Security
Chief Engineer
- Gets no special domain, because no other Head roundstart trims receive
access to the CE's high-security areas of Engine or Atmospherics
(besides Captain, who has a neutered remote already)
Research Director
- AI Upload, AI Core
Chief Medical Officer
- No special domain for the same reason as Chief Engineer; no other
heads have unmitigated medical access
Also updated remote descriptions with allusions to stereotypes/jokes for
a given head (Captain's authority is dubious, QM is not a Real Head,
Security remote was stolen from HoS by resentful Warden, HoP disappears
more than Carmen Sandiego, CMO shouldn't have a medical license, RD is
absolutely jacked)
Finally, moved the remote definitions to be above the sheer cliff of the
ranged interaction proc in the control_wand file.
## Why It's Good For The Game
Makes remote access have parity with the access of their respective head
of staff, while at the same time allowing other Heads of Staff to retain
their own control over doors in their department areas.
## Changelog
🆑 Bisar
balance: Door remotes now match the access of their owner (except for
the Captain, whose remote access is unchanged). Door remotes, however,
respect the high security area control of other remotes; as such, even
if a Head can enter an area like the brig, only the Security remote
works to open the entrance.
/🆑
## About The Pull Request
This trainwreck of a PR is (hopefully) a final solution to all rendering
jank stemming from the new filter-based coloring system. I went over
every single instance of RESET_COLOR, either adding KEEP_APART or
rewriting them entirely so they render properly. I've also fixed blood
rendering issues by utilizing alpha filters and adding an abstract
"holder" appearance for worn items, which holds blood overlays on worn
clothing as to avoid coloring it. I've also fixed horrible
inconsistencies with atmos pipe coloring as a result (of getting sucked
down that rabbit hole) and converted all uses of COLOR_VERY_LIGHT_GRAY
in atmos code to ATMOS_COLOR_OMNI to avoid confusion.
MODsuit modules still get colored into MOD unit's color, need to
refactor their rendering for this.
Closes#88989Closes#87526Closes#89837
## Changelog
🆑
refactor: Audited all remaining coloring code - among noticeable
changes, blood should no longer get colored or "leak out" of item
bounds, atmos pipes no longer color weirdly and repairbots are white
again.
/🆑
## About The Pull Request
These two should be ITEM_INTERACT_BLOCKING to prevent accidentally
bashing them when failing to use the tool for whatever reason
## Changelog
🆑
fix: Fixed failed wrench/welder interaction attempts resulting in you
attacking reflectors
/🆑
## About The Pull Request
A Huge chunk of changes just comes from moving existing storage code
into new files & seperating `atom_storage` code into its own subtype
under the already existing `storage/subtypes` folder.
With that the changes in this PR can be organized into 3 categories.
**1. Refactors how `/obj/item/storage/PopulateContents()` initializes
storages**
- Fixes#88747 and every other storage item that has a similar variant
of this problem
The problem with `PopulateContents()` is that it allows you to create
atoms directly inside the storage via `new(src)` thus bypassing all the
access restrictions enforced by `/datum/storage/can_insert()` resulting
in storages holding stuff they shouldn't be able to hold.
Now how this proc works has been changed. It must now only return a list
of items(each item in the list can either be a typepath or a solid atom
or a mix of them in any order) that should be inserted into the storage.
Each item is then passed into `can_insert()` to check if it can fit in
the storage.
If your list contains solid atoms they must be first moved
to/Initialized in nullspace so `can_insert()` won't count it as already
inserted. `can_insert()` has now also been refactored to throw stack
traces but explaining exactly why the item could not fit in the storage
thus giving you more debugging details to fix your stuff.
A large majority of changes is refactoring `PopulateContents()` to
return a list instead of simply creating the item in place so simple 1
line changes & with that we have fixed all broken storages(medical
toolbox. electrical toolbox, cruisader armor boxes & many more) that
hold more items they can handle
**2. Organizes initialization of `atom_storage` for storage subtypes.**
All subtypes of `/obj/item/storage` should(not enforced) create their
own `/datum/storage/` subtype under the folder `storage/subtypes` if the
default values are not sufficient. This is the 2nd change done across
all existing storages
Not only does this bring code cleanliness & organization (separating
storage code from item code like how `/datum/wire` code is separated
into its own sub folder) but it also makes storage initialization
slightly faster (because you are not modifying default values after
`atom_storage` is initialized but you are directly setting the default
value in place).
You now cannot & should not modify `atom_storage` values inside
`PopulateContents()`. This will make that proc as pure as possible so
less side effects. Of course this principle is not enforced and you can
still modify the storage value after `Initialize()` but this should not
be encouraged in the future
**3. Adds support for automatic storage computations**
Most people don't understand how `atom_storage` values work. The comment
here clearly states that
55bbfef0da/code/game/objects/items/storage/toolbox.dm (L327-L329)
Because of that the linked issue occurs not just for medical toolbox but
for a lot of other items as well.
Which is why if you do not know what you doing, `PopulateContents()` now
comes with a new storage parameter i.e. `/datum/storage_config`
This datum allows you to compute storage values that will perfectly fit
with the initial contents of your storage. It allows you to do stuff
like computing `max_slots`, `max_item_weight`, `max_total_weight` etc
based on your storage initial contents so that all the contents can fit
perfectly leaving no space for excess.
## Changelog
🆑
fix: storages are no longer initialized with items that can't be put
back in after taking them out
refactor: storage initialization has been refactored. Please report bugs
on github
/🆑
<!-- 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
[Removes all remaining users of SMOOTH_CORNER + dirt
automation](71d120511a)
Removes all remaining instances of overlay smoothing (the deprecated
system that stitches corners together IN ENGINE) from the game.
This amounts to:
The test smoothing wall, which I converted to just bitmask + diagonals
Stationary canisters, which I've done the same to (alongside adding all
the states to gags, which around doubled their gags count). These
autocut now.
I've also given dirt icons autocutting, for spriter convieneince (I
would have done this before but I didn't know they smoothed)
[Removes corner smoothing from the
codebase](98ebe58152)
This code is OLD, and has been functionally deprecated for as long as
I've been here. It basically does what bitmask smoothing does, but
instead of prebaking connections they're formed in engine with overlays.
This is... fine, and does TECHNICALLY allow for unique effects, but
none's gonna use it because the details are so niche, so it just becomes
a risk factor for someone fucking up and using overlays for some reason.
What it does do then is clutter up our smoothing code with 2 different
async systems, one of which functions SLIGHTLY differently from its
brother. IMO it just works to confuse people trying to read smoothing
code (already quite confusing).
I've removed it, alongside its bespoke code/variables, excluding
area_limited_icon_smoothing, a var on areas that prevents smoothing out
of network, which I have instead integrated into bitmask smoothing.
I've updated snowflake's documentation to be more up to date with modern
systems, and earmarked where explanations/automation for the more...
underdeveloped bits of smoothing should go in the future.
## Why It's Good For The Game
I relapsed and needed something to put that energy towards.
We don't really want people to use this, and none knows enough about it
to take advantage of its theoretical uses.
Really its only purpose right now is making understanding diagonal
smoothing easier, and that's not all that hard of a task.
Better to remove and integrate then to let rot and confuse.
## 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 its 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. -->
🆑
add: Smoothed objects on shuttles now will only smooth with other
shuttles (added support for extensions of this system)
refactor: I've funked around with our smoothing system, cutting out some
older code. Lemme know if anything is weird PLEASE
/🆑
<!-- 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. -->
## About The Pull Request
In #89619, I removed the mech PKA's mining AOE and reduced the damaging
AOE to a fraction of the damage.
I have restored both of these aspects, but I have also applied this
change to the standard PKA's mining and damage AOE. I have also included
the mob biotype limitations as well.
AOE modkits take 10% capacity, now allowing miners to use them in more
setups. However, they conflict with one another. You can only have one
AOE mod until you can get the dual AOE mod from tendrils.
The AOE damage/mining effect is now a 2 tile effect rather than 1 tile
effect.
## Why It's Good For The Game
My intent in the previous PR was to bring mech PKA's down to standard
mining limitations. So, why not improve those standards for everyone
instead? The new state of mining expects you to be dealing with a lot of
mobs at once. Even small vents can, on occasion, decide to spit out
several goliaths back to back. That's a lot of mobs with a lot of
health.
Miners need AOE options more than ever. They have very little that are
actually meaningful, sadly. So my intent here is that this should be an
expectation for our miners to be seeking out and can fit into their
current, standard gameplay.
Certainly I've only felt like shit having to sacrifice a damage or
cooldown mod for an AOE mod, only to get a very minor amount of damage
splash for my efforts. That, and the radius doesn't usually impact most
mobs as they spawn and attack from awkward angles or distances from one
another where they are JUST out of reach of one another. Trying to use
the splash to hit multiple enemies is often not worth it compared to
just hitting one enemy at a time with a lot of damage.
So, let's just go with the standard of 'Good AOE is fundamentally needed
now' and worth from that premise.
## Changelog
🆑
balance: Mech PKA now once again mines turfs and does full damage on its
AOE explosion (still only hitting mining mobs).
balance: The standard PKA AOE mods are now by default 10% capacity. But
they cannot be used with one another.
balance: The standard PKA offensive AOE mod now does the PKA's full
damage in its AOE.
balance: Mining AOEs will affect everything within a 2 tile radius
around the point of impact, up from a 1 tile radius.
/🆑
---------
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
## About The Pull Request
Added visual overlays for all arm implants, HUD implants (not the
headrev one), internal thrusters, breathing tube, nutriment pumps and
reviver implant.
Additionally, added a wrapper for eye color setting which solves the
issue where non-pref sourced eyecolors got reset after changing them,
and changed how blinking works so now update_body calls don't force you
to blink.
## Why It's Good For The Game
Gives you incredible drip (which makes augments feel more impactful) and
allows others to see if you have certain important augments (reviver)
that could matter.
As for technical changes, both were required for this to HUDs to work
nicely and fix some bugs as a side effect.
## Changelog
🆑
add: Certain implants now have visuals when implanted
fix: You no longer blink when you adjust your clothing
fix: Fixed an issue where some NPC/midround humans would not get their
eye color set correctly
/🆑
## About The Pull Request
So I was looking for `attackby(...)` instances to kill and, hey look,
table frames- oh what the fuck is this.
Oh why does this have the same checks like five times, across the parent
type and subtypes.
So this pr's primary point is to refactor the table frame
`attackby(...)` into `item_interaction(...)`, and by extension lower the
amount of weird `attackby(...)` override jank going on with them.
Instead of having all of the subtypes define their own almost exactly
the same table construction interactions, we use a single generic
interaction chain and add a new `get_table_type(...)` proc to let
subtypes override what tables to construct for what stacks.
We also move the assigning of frame-and-stack-related things to the
actual table types themselves, instead of specifying all these
interactions on the frame.
We also add screentips for deconstruction and table construction, again
using the `get_table_type(...)` proc so screentips can differentiate
between which stacks can and can't make a table for our table without
needing to change the screentips manually for the subtypes.
Beyond that is mostly generic clean-up.
I'm a bit icky on my implementation of
`/obj/item/stack/proc/get_table_type()`, because of hardcoding for
`/obj/structure/table/greyscale`, but I think it's better than the
alternatives.
This lets us use the old method of letting all `/obj/item/stack/sheet`
subtypes use the generic material table, but limit it to working as long
as they define a `material_type`. I feel it's better than letting broken
tables exist, needing to hardcode it on the table frame, or needing to
expect people to add the generic material table `table_type` whenever
they add a `material_type` (no one would do this).
## Why It's Good For The Game
Screentips good 👍
Less jank encountered good.
Specifically the inability to deconstruct table frames on right click
when tables can be deconstructed on right click has thrown me off so
many times it's wild.
## Changelog
🆑
refactor: Refactored table frame interactions, please report any issues.
fix: You can no longer make material-less material tables out of certain
items.
fix: Fancy tables remember which carpet was used to make them, and no
longer magically transmute carpets into simpler types.
fix: You can no longer stack abductor table frame-using tables
specifically.
qol: Added screentips for deconstructing table frames and constructing
tables out of them if the material you're holding can do so.
qol: Table frames can now also be deconstructed on right click for
parity with tables, in addition to left click.
qol: Table frame interactions use balloon alerts.
/🆑
## About The Pull Request
Refactors martial arts off the mind. Don't worry the martial arts you
learn still transfer with mindswap
Instead, they are just tracked on a list on the mob, and they also
independently track the datum that created them
This fixes a lot of jank with martial arts, like say, having your krav
maga gloves transfer across slime clones or something...
But it also opens an opportunity: As we track all martial arts
available, I added a verb (ic tab) that lets you swap between the ones
you know
(Some don't let you swap like that one brain trauma)
## Why It's Good For The Game
Aforementioned fixes a lot of jank
Recently martial arts have just been up and disappearing and this was
entirely spurred on by that bug
Probably fixes#84710 (haven't checked)
Probably fixes#89247
Probably fixes#89948
Probably fixes#90067
## Changelog
🆑 Melbert
refactor: Refactored martial arts, if you notice any oddities like
managing to know two martial arts at once or having your powers
disappear, report it!
add: If you know multiple martial arts, such as krav maga from gloves
and cqc from a book, you can now swap between them at will via a button
in the IC tab!
/🆑
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
I was kinda shocked that we didn't have something for this considering
that it's an unspoken rule of cargo to check that a crate does not sell
back for more than it's price and that the one comment saying to do so
has been doing some heavy lifting for the last 12 years.
I'm a novice when it comes to unit testing specifically so hopefully the
smoothing out that needs to be done should be fairly quick.
*Edit (2/22/25):*
The following changes were also made in order to allow for this unit
test to work smoothly:
Exports now have a market define added to them, as the purpose of this
unit test is to test exports that occur on the station, bought from
supply and then sold back to supply. As such, these market defines
exclude exports specific to pirates (since the cargo shuttle cannot sell
living mobs back, preventing you from making 10k per parrot crate.).
I've also added the `abstract` variable to some export datums, to
signify that a given export is either variable, or not meant to be
compared against the value of it's own container, such as with gas
canister's base export value as their export datums are generated
dynamically. (The subtypes are not abstract, however.)
The verb, `/mob/living/verb/tally_physical_credits()` has been changed
to `/mob/living/proc/tally_physical_credits()`, because that's my B and
does effect some economy back end but it's a one line fix so I just
absent-mindedly fixed it here instead of atomizing it out. I can
one-line it otherwise.
Mulebots now no longer runtime on spawn as they set their own to their
own `get_turf` as opposed to pulling their `loc`.
A few supply packs have had their prices bumped up slightly to actually
pass the test itself:
* `/datum/supply_pack/misc/candles_bulk`
* `/datum/supply_pack/security/armor`
* `/datum/supply_pack/security/helmets`
* `/datum/supply_pack/security/baton`
## Why It's Good For The Game
Prevents future infinite credit bugs that could have been missed by
simply checking the sale value in game.
## Changelog
🆑
fix: To prevent infinite sales issues, security helmets, armors, and
batons packs now all cost 600 credits, up from 400.
fix: Candle packs now cost 400 credits, up from 300, and candles now
sell for 12.25 cr each.
/🆑
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
## About The Pull Request
Simply stops this from `stack_trace()`'ing in ruins, opting to
`log_mapping()` instead. By changing it to use `log_mapping()` it will
only cause CI failures if they occur on mining or station z levels,
which should stop ruins weirdness from causing garbage outputs/failures
in tests.
As well as improving the debug logging by adding the area to the
printout.
## Why It's Good For The Game
There's really no point to complaining about a ruin spawning overlapping
lattices after mapload when one of them just gets deleted anyway. Stops
unhelpful stack_trace messages from blocking CI from passing.
## Changelog
Not player facing.
## About The Pull Request
Turns out you need to set sign change name for it to be selectable on
blank signs
I thought this was a big footgun so I just added logic to have signs
default to their name if they are editable but don't have a change_name
set.
## Changelog
🆑 Melbert
fix: You can make eye charts out of blank signs
/🆑
## About The Pull Request
Vents/scrubbers look a bit weird as their pipes still go above
catwalks/glass floors but I need my stuff from #89702 and it should be
atomized from this PR.
Closes#87022Closes#88823
## Changelog
🆑
fix: Fixed spiderwebs, alien weeds, kudzu, and other stuff layering
below catwalks and glass floors
/🆑
## About The Pull Request
adds a paper that lists which blood can receive what to blood pack
crates (in medical and cargo)
hope its correct
## Why It's Good For The Game
if you happen to not know blood types this is a better reference ingame
without needing to tab out
## Changelog
🆑
qol:adds a paper that lists blood compatibility to blood pack crates
/🆑
## About The Pull Request
Closes#89676
Also fixed an evil and bad runtime that prevented leaners from falling
when the atom is destroyed/moved
## Changelog
🆑
fix: You can now lean on falsewalls
/🆑
## About The Pull Request
Adds airtight flaps to cold rooms on all maps
This includes:
- Kitchen Cold Room
- Medbay Cold Room
- ...For maps with them. Not all of them do.
- Additionally, all maps with medbay cold rooms are now properly cold
rooms.
- RND Server Room
- Xenobio Kill Room
- Telecomms
This also includes maintenance doors on all mentioned rooms, though I
don't know if they should or should not.
Also, flaps now burn if in very hot environments.
Also, I tweaked the layer of flaps so you can click doors through them.
Open doors. Shouldn't affect the visuals.
Also, flaps now have a sound for walking through them. Not crawling
though.
## Why It's Good For The Game
The actual initial reason I did this is because IRL when you walk
through a coldroom you go through the flaps and I wanted to add that,
because it's a funny chef thing.
But they do actually serve a purpose, they block cold air from escaping.
So I figured it would be sensible to put them in places where rooms are
intentionally kept cold.
As you know, these rooms will often spill their cold air out and cause
firelocks to fall, which is just very very annoying. It doesn't really
let us play around with cold air as a gameplay mechanic because it
spreads so aggressively and causes firedoors.
So they now serve twofold:
1. Blocking cold air from causing firelock air in these certain areas
2. Chef larp
If the fact that they block air is troublesome so some maintainer(s),
I'll probably just bump it down to being cosmetic flaps. Cause that was
the original goal anyways.
(Or maybe we can come to an agreement to change the flaps to only block
a portion of air or something)
(The melting was added as a way to keep fire deadly)
## Changelog
🆑 Melbert
add: The Kitchen Coldroom, RND Server Room, Xenobio Kill Room, and
Telecomms on all maps now come equipped with walkable, transparent
airtight plastic flaps.
add: Medbay Coldrooms are now consistently cold across all maps that has
one. They, too, now have plastic flaps.
add: Plastic flaps will now melt in hot environments / active fires.
Cargo flaps are more resilient to fire than kitchen flaps.
qol: Open doors no longer layer beneath plastic flaps, in other words
you can actually click on them to shut them.
qol: Plastic flaps may be less irritating to traverse for things which
can already pass through glass
sound: Walking out of plastic flaps now has sfx. Crawling out is still
silent.
/🆑
## About The Pull Request
This incredibly detailed PR adds the ability to construct custom
shuttles, which function similarly to whiteships.
To construct a custom shuttle, you need the following items:
- Shuttle frame rods
These rods can be hand-crafted by using 5 rods on 1 sheet of titanium,
or printed at a sci/engi/cargo lathe after researching the Shuttle
Engineering techweb node.
Lattices built with these rods, and catwalks/floors built on top of
these lattices, are valid for shuttle construction.
- Shuttle engines
Did you know shuttle engines have boards that weren't normally
obtainable? Well the board for one specific engine type is now available
from the sci/engi/cargo lathe after researching Shuttle Engineering. Of
course, the old options remain. You can steal engines from other
shuttles, including escape pods (it's not like engines are strictly
necessary for *those* shuttles anyways). Alternatively, the shuttle
engine supply pack is no longer locked behind the purchase of the BYOS.
- Flight Control & Navigation Console boards
These boards are printed at the sci/engi/cargo lathe after researching
the Shuttle Engineering techweb node.
If built on a custom shuttle, it will automatically link to it, unless
the shuttle already has such a console.
If built on a turf that is valid for custom shuttle construction, it
will automatically link to any shuttle constructed from or expanded with
that turf.
- Shuttle blueprints
Standard shuttle blueprints can be printed at the sci/engi/cargo lathe
after researching the Shuttle Engineering techweb node.
A cyborg upgrade granting access to a shuttle blueprint database can be
printed at the exofab after researching the aforementioned node.
Crude shuttle blueprints can be crafted by hand with a sheet of paper
and either a rainbow crayon or 10 uses of a blue crayon or spraycan.
If Science won't research the tech, you can also buy a goody pack
containing a flight control board, a docker board, two engine boards,
and a set of shuttle blueprints for 1200 credits, if you have aux base
access.
A shuttle can be constructed atop any continuous region of turfs
containing a shuttle rod lattice or a catwalk/tile built upon such.
Currently, this region cannot intersect any area other than space,
lavaland, the icemoon, or the station asteroid. Preexisting custom areas
can be included in the construction of the shuttle, but only if every
turf in the custom area is valid for shuttle construction.
In the shuttle blueprint UI, you can toggle a visualizer to display
which turfs fulfill all of the aforementioned conditions.
The following video goes through the basic process of shuttle
construction.
https://github.com/user-attachments/assets/3283422e-a201-4978-972d-67527b5df4ee
The blueprint used to construct the shuttle will be its master
blueprint. The master blueprint can be copied to other blank shuttle
blueprints (or to engiborgs with the shuttle database upgrade), and
allows the holder to perform a christening ritual on the shuttle to
rename it.
If a shuttle's master blueprint ceases to exist, a blank blueprint can
be linked to the shuttle to become the new master blueprint, or an
existing blueprint associated with that shuttle can be promoted to the
master blueprint.
Once constructed, the following options are available from the blueprint
UI to modify it:
- Create Area
Convert a continuous open area of the shuttle into a new area with the
name written in the above text input. This operates very similarly to
regular area construction.
- Rename Area
Change the name of the area you're currently in to the name written in
the above text input.
- Expand Area
Add a continuous open area of the shuttle to the neighboring area
selected from the dropdown to the left. This operates like regular area
expansion.
- Expand Shuttle
Expand a shuttle with valid frame turfs as defined above. These turfs
must be physically connected to the shuttle.
- Remove Area
Remove an area, giving its tiles to the default shuttle area.
- Cleanup Empty Space (implemented after the above video was recorded)
Removes all completely empty turfs from the shuttle. If all the turfs in
one of the shuttle's areas were removed, that area is deleted. If
absolutely no turfs of the shuttle remain, the shuttle itself is
deleted. Due to the ability for this action to delete the shuttle, only
the master blueprint can do it.
As mentioned above, the shuttle's master blueprint can be used to
christen its associated shuttle. To do this, fill a glass drink bottle
with some amount of reagents, then hit it against one of the shuttle's
walls from outside while holding the master blueprint. You will be
prompted to enter a new name for the shuttle. The variety of things that
can happen while inputting a new name can cause the christening rite to
fail in one of several humorous ways.
### Optional (Unless specifically requested by a maintainer) Todo's
- [x] A way for shuttle circuits to be obtainable without techweb nodes
- [x] A more convenient way to carry around shuttle engines or the means
to deploy them
- [ ] A shuttle construction guide available as a reference book
- [ ] Allow boards to be linked to shuttles before construction so they
can be used outside the shuttle
## Why It's Good For The Game
Shuttles have been part of the sandbox for an incredibly long time, but
their limited accessibility has rendered them the exclusive territory of
lucky space explorers or the few antagonists who get one off the bat
(nukies and pirates). Giving players the means to construct shuttles to
their liking opens up a variety of possibilities for gimmicks for antags
and non-antags alike.
Besides the applications for antaggery and crew-sided gimmicks, this
provides side content for several departments to engage with during the
relatively-frequent periods of time where they have little else to do as
part of their intended roles.
With respect to engineering, if the station isn't actively being
damaged, the supermatter is in perfect working order, and nobody is
clamoring for machine upgrades, engineers have little else to resort to
other than construction projects. While the BSA station goal provides an
incentive for engineers to construct dedicated rooms for the cannon, it
will not necessarily be available every round. Custom shuttles not only
provide such a construction project to pursue, but provide the rare
opportunity, as well as a very good reason, to set up an independent
power network, complete with its own power source.
While atmos techs have a lot to do with gas mixing and the crystallizer,
they rarely get the opportunity to set up working life support systems
outside of repairing the ones that get blown up. Custom shuttles will
frequently start with no air, and unless the design settled upon is an
open floor plan, it will have several independent chambers that cannot
so easily be profused with a proper airmix by just opening a canister.
Furthermore, if the air in a custom shuttle gets messed up, a proper
scrubber and distro network is a significantly less tedious method of
rectifying the problem than cleaning the air manually with portable
scrubbers and pumps.
Scientists, it can be argued, with their access to RPDs through
ordnance, have similar opportunities to atmos techs, even though the act
in and of itself is not exactly part of their duties. But compared to
the other job content they could be working with after they've completed
most of their gameplay loop, custom shuttle construction is a
substantially more active endeavor. And I know how much people complain
about late-game science content just being sitting around at a console
and making gamer gear. Roboticists can have a part to play in this too.
They can put their mech RCDs to a use other than 2D topdown Fortnite,
and with the shuttle database upgrade, they can help interested cyborgs
get in on the action.
Cargo is yet another department known for having significant amounts of
downtime during a considerable number of rounds. If every other
department has gone through their initial rounds of departmental orders,
and there isn't an active need for cargo to order lots of one thing or
another, cargo techs have little to do besides mail (at least on the
days where there **is** mail to deliver). Usually, if cargo techs do, in
fact, do something as a department when not presented with more pressing
duties, they order guns and other contraband. As funny as this is,
there's not a lot of variety in how this behavior manifests. With custom
shuttles, cargo can use their free time to plan, and execute, a unique
collective expression of design sensibilities, not limited by the size
and shape constraints of the cargo bay itself.
## Changelog
🆑 Y0SH1_M4S73R (with special thanks to Vect0r, whose original PR
inspired the implementation of these changes)
add: Shuttle blueprints, the tool used to construct and modify custom
shuttles. Print a set at a science, engineering, or cargo techfab after
researching Shuttle Engineering, or craft a crude set from the crafting
menu.
add: Shuttle blueprint database upgrade for engineering cyborgs,
printable from the Exosuit Fabricator after researching Shuttle
Engineering. A version of shuttle blueprints designed for use by
cyborgs.
add: Shuttle frame rods, usable to construct custom shuttles. Hand-craft
by using 5 rods on 1 titanium sheet, or by printing them at a science,
engineering, or cargo techfab after researching Shuttle Engineering.
add: Custom shuttle flight control and navigation boards, printable from
a science, engineering, or cargo techfab after researching Shuttle
Engineering.
add: Shuttle engine boards can be printed from a science, engineering,
or cargo techfab after researching shuttle engineering.
add: The shuttle engine supply pack is no longer locked behind the
purchase of the Build Your Own Shuttle kit.
add: Shuttle Construction Starter Kit goodie pack, containing a set of
shuttle blueprints, flight control and navigation console boards, and
two engine boards, can be purchased from cargo for 1200 credits.
Requires aux base access to purchase.
refactor: Shuttles now keep track of what areas are underneath each of
their individual turfs, so that the areas left behind on movement are
consistent with what they were beforehand.
refactor: Shuttle ceilings now place themselves down as baseturfs,
instead of only appearing if the turf above is open space.
/🆑
---------
Co-authored-by: vect0r <71346830+Vect0r2@users.noreply.github.com>
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
Co-authored-by: necromanceranne <40847847+necromanceranne@users.noreply.github.com>
## About The Pull Request
Fixes#88607
Soft-requires #89358 since I used a proc I added in that in this PR
Mirror reflections from all directions now work as you would... maybe
expect them to work
Becoming a Vampire while in front of a mirror makes you immediately
disappear
https://github.com/user-attachments/assets/d9426da4-1cdc-446f-b501-fdab3ba1a32c
## Changelog
🆑 Melbert
fix: Mirror reflections should be more accurate now
fix: Becoming a Vampire while standing in front of a mirror correctly
vanishes you (rather than waiting to exit and enter the mirror's view)
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
- Adds sanitization to windoor names and circuit shells.
- Fixes a (mostly useless) href exploit with wizard's contracts.
## Why It's Good For The Game
Sanitizing input is probably good.
## Changelog
🆑
fix: Fixed a few sanitization issues.
/🆑
## About The Pull Request
Pre-discussed with @Watermelon914, this PR removes Secondary & Final
Objectives from all Traitors, rather than just midround ones. It also
removes all of the surrounding supporting code.
Randomly assigned Primary Objectives still exist, I just used the
ability to rewrite mine to take the screenshot.
In terms of final objectives, the surrounding items that were available
still exist but don't necessarily have sources.
If anyone has good ideas for readding these in some other form it can be
done in future PRs.
It also allows all traitors to buy the Contractor kit, previously
limited to midround traitors which lacked secondary objectives, because
now all traitors lack secondary objectives.
This essentially limits all traitors to a maximum of 20 TC (16 if they
spawn with an uplink implant). Currently I don't foresee that they
strictly need any additional way of gaining TC during a round as 20 is
quite sufficient, but it may take some time to adjust and get used to it
after such a long time of having access to more. If we need to adjust
the starting value or add a slow drip of more points over time or
something, that can be done in followup PRs.
This also removes the ability to recreate your uplink added by my
beautiful wife in #74315
This was part of the progression traitor design document, but ultimately
probably a bad idea as it essentially made traitors impossible to
properly disarm. You will once more just need to carefully protect your
uplink.
**This does not remove the threat/progression system**.
Like midround traitors, all Reputation requirements on gear are now
simple timelocks, most of which will have elapsed by the time 30 minutes
have passed.
**Finally** this PR also adds Romerol to the traitor uplink for 25 TC
and 30 minutes of reputation, as a treat (and because I removed the
final objective that previously granted it).
## Why It's Good For The Game
We've tried this system for a long time (3 years last month!) and while
I think it had a lot of promise, enabled some cool moments, and also
solved several of the problems it set out to solve, overall I think some
of the behaviours it has encouraged in players have been overall
negative for the game.
While the _game systems_ are fine, even quite fun and cool (especially
final objectives) I am of the opinion that having them in the game
creates a net negative purely in the way that they react with players'
_brains_, creating incentives towards behaviour we don't actually want
people to pursue.
While it's hard-to-impossible to prove any of this with hard data, there
has been a prevailing feeling for some time among many (though certainly
not all) people that the simple fact of _having_ a constant drip-feed of
objective available to players leads directly to less interesting
antagonist play. While certainly nobody is _forced_ to do secondary
objectives you are directly and quite strongly rewarded for doing so,
doing so efficiently, and doing so in a way which makes sure that nobody
(alive) sees you do it. This leads to a tendency to play defensively and
try to maximise the number of tasks you can complete in one round, which
also has a knock-on effect of generally minimising the number of people
you attempt to interact with in a round (unless you are killing them).
Even people who _intend_ on doing some more interesting gimmick can fall
into this trap, as "having more tools" is always useful for anyone who
is intending on any kind of plan at all, but then executing on the
secondary objectives again incentivises you to lay low, not interact
with anyone, be efficient, and then reduces the time you are spending
doing the thing that's your actual plan for the round. Removing the
ever-present temptation to fish for extra TC leaves "doing whatever your
actual plan is" as the sole thing to optimise.
Final Objectives too have created unfortunate psychological effects
between crewsided players and other antagonists. Because of the _threat_
(no matter how remote, Final Objectives have always been tuned to be
appropriately rare) that leaving any antagonist alone will cause them to
snowball by acquiring more power, it starts to feel foolish to respond
to any threat with less than the maximum possible level of force even if
they seem relatively innocuous in the moment. This even has an effect on
other non-progression antagonists, as traitors are the most common
antagonist type and how people treat them is going to be their default
level of reaction to most other station threats.
While there has always been the promise of expanding the system with
novel and exciting objectives that leverage appearing mid-round to do
something unique, we've taken very little advantage of that over time.
Most objectives we have added that didn't boil down to "kill someone,
with a twist" have been somewhat unsuccessful, serving either as ways to
get yourself arrested and killed for no reason or ways to get free
telecrystals by doing something the crew don't really care about
stopping you from doing. The option still exists to add more roundstart
objectives to traitors, if someone suddenly has a great idea that would
fit in this space.
The ideal outcome of making this change is a slight relaxation of crew
attitude towards feeling like their only option after catching an
antagonist that isn't sandbagging is to permanently remove them from the
round (although it's fine to do this still in many scenarios), and a
broadening of traitorous activity which is not purely focused on
collecting as many checkboxes as possible and might give people more
time to roleplay with other players, not worrying that this time could
have been more efficiently spent pursuing a different secondary goal.
I don't anticipate or desire that this will prevent traitors from
killing anyone (or even stop them from killing people they don't have a
specific objective to kill), I just want to remove the FOMO from
people's minds.
Also this gives us something to talk about at the coder townhall meeting
on the 22nd.
## Changelog
🆑
del: Misplaced or stolen traitor uplinks can no longer be recreated
using a radio code and special device, guard yours carefully or buy a
backup implant.
del: Roundstart traitors can no longer take on additional objectives in
order to earn additional Telecrystals and fast-forward any unlock timers
on items. They also cannot earn the ability to complete a Final
Objective.
balance: Roundstart traitors can now buy the Contractor Kit from their
traitor uplink, rather than only midround traitors.
add: Traitors can buy Romerol for 25 TC, after 30 minutes of time has
passed in a round.
/🆑
## About The Pull Request
Fixes#85980
- Pixel adjustments are now sourced
When tweaking a mob's pixel w, x, y, z, is is now done via `add_offsets`
and must have a source string associated
- Refactors riding
Refactors how riding component selects the offsets to use. It's now all
done via the getter rather than a weird mix of a var, a cache, and a
getter.
- Moves a bunch of animations to use `pixel_w` / `pixel_z`
Largely to prevent conflicts with adjustments to a mob's pixel position,
but also as many animations are not actual movements, but visual
movements. Floating is one such example.
## Why It's Good For The Game
It just works
## Changelog
🆑 Melbert
fix: Fixed grab offsets not showing for anything but passive grab
fix: Fix jank with mob offsets when riding things
refactor: Refactored riding component, particularly how it selects layer
and offsets. Report any oddities
refactor: Refactored pixel offsets of mobs. Report any oddities
/🆑
## About The Pull Request
del() log, radio log, check antagonists, law/dna/fingerprint logs all
use browser instead, which means darkmode, wahoo
The only difference now is that they are in darkmode, really.
Also removed browse calls to pipe dispensers (the machine) and windoor
assembly, as they both use TGUI now so these don't do anything.
Lastly, adds an early return to the tram admin tool if you don't select
a tram, cause I found it annoying.
## Why It's Good For The Game
Try to use old admin tools, get flashbanged
## Changelog
🆑
admin: Check antagonists & del/law/dna/fingerprint/radio log panels use
browsers which means they have darkmode. Also the tram panel will cancel
out if you click cancel.
/🆑
## About The Pull Request
4 variations of drop and pickup, applied to bedsheets, pillows,
bandages, regen meshes, surgical drapes.
We had a cloth drop/pickup sound but I didn't think it fit the stuff I
was applying it to so I made new ones, the old ones are still in just
renamed to cloth_...1.ogg
https://github.com/user-attachments/assets/60575f1e-56fd-489b-b363-49abd146cece
## Changelog
🆑 grungussuss
sound: new sounds for cloth items
/🆑
## About The Pull Request
Adds slips to the list of existing shove stun methods originally set in
https://github.com/tgstation/tgstation/pull/84640 (wall shoves,
telebaton, mansus grasp), and also reifies this concept as the "dazed"
status effect.
This makes it so that being knocked down from a slip from any source
(e.g. wet floor, clown stuff, lube, foam, oil, butterdog) gives the
dazed visual effect and makes you eligible for being shove stunned. The
status always lasts for 3 seconds even if e.g. slipping on lube knocks
you down for 15, but this can be customized per slip.
## Why It's Good For The Game
Further rewards environmental play and provides another feasible means
of fighting back against better equipped opponents, both in line with
the original PR. Also the visual cue fits well as an immediate signal
that you're dazed and can't get up.
## Changelog
🆑
balance: slips now make you eligible for being shove stunned
/🆑
---------
Co-authored-by: Roryl-c <5150427+Roryl-c@users.noreply.github.com>
<!-- 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
Fixes#89261 by adding the thing
This loop was present prior to #88465 , but it seems like it was deleted
by accident together with some check
<!-- 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
Bug fix
<!-- 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 its 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. -->
🆑
fix: showers wash things under them when they're turned on again
/🆑
<!-- 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. -->
## About The Pull Request
Commit messages should be descriptive of all changes.
The "incorrect `\The` macro capitalization" was intentional when it was
added, but as far as I know TG says "the supermatter" rather than "The
Supermatter," so it's incorrect now.
This is completely untested. I don't even know how you'd go about
testing this, it's just a fuckton of strings.
Someday I want to extract them and run NLP on it to catch grammar
problems...
## Why It's Good For The Game
Basic grammar pass for name strings. Should make `\the` work better and
avoid cases like `the John Smith`.
## About The Pull Request
Refactors the way we listen for reagent changes. The changes made can be
listed as points
**1. Removes `COMSIG_REAGENTS_PRE_ADD_REAGENT`**
Used to stop new reagents from being added to the holder, its only
application is with the BRPED to stop inserting reagents into
beakers/cells stored inside it.
Rather than using this signal a cleaner solution is to simply remove the
component part's reagent holders' flags which allow us to insert
reagents into it(i.e. `REFILABLE`, `INJECTIBLE`, `DRAINABLE`) and
restore them back when that part is removed thus achieving the same
results.
Thus `add_reagent()` is now slightly faster because it no longer uses
this signal
**2. Removes every other signal used by the reagent holder**
Removes pretty much every other signal used by `holder.dm` which are
`COMSIG_REAGENTS_[NEW_REAGENT, ADD_REAGENT,
DEL_REAGENT, REM_REAGENT, CLEAR_REAGENTS]`
While yes, it is true that all these signals are unique & serve a
specific purpose the problem is no object in code respects their
uniqueness & instead clumps them up all together & hooks them onto one
proc to listen for "reagent changes". You see this code pattern repeated
in so many places
9277364ef6/code/modules/power/power_store.dm (L105)
Not only does this look ugly but it also has a memory overhead (4 to 5
signal slots all performing the same action which is a lot compared to
the solution i implemented below). Bonus is that "none" of the
parameters passed to this proc are used so they go to waste as well.
So after removing a ton of code we need something that can still make
the code function which brings us to point 3
**3. Adds a new signal `COMSIG_REAGENTS_HOLDER_UPDATED` to rule them
all**
So if all objects in game are listening for "reagent
changes"[adding/removing, reagents] then we need to look at the proc
that is always called during these changes & that is none other than
`update_total()` so we let that send out a signal and cause all objects
to hook onto this 1 signal instead of 4 to 5 signals as explained in
point 2
## Why It's Good For The Game
This section isn't necessary but i want us to better appreciate both the
code & performance benifits of this PR.
1. First of all its waaaay less code and signals to worry about. Just
look at the number of lines of code removed compared to added. Nothing
more to say
2. Overhead of `RegisterSignal` compared to `RegisterSignals` is less
for obvious reasons
3. `remove_all` is significantly faster as it no longer calls
`remove_reagent()`[which in turn calls `update_total()` &
`handle_reactions()` per call & uses a for loop so its a nested for loop
of doom] for every reagent it removes, instead it does the work by
itself & calls the above 2 procs just once
4. Usually when a reagent is deleted it calls
`COMSIG_REAGENTS_REM_REAGENT` & `COMSIG_REAGENTS_DEL_REAGENT`. So if you
have a holder with like 3 reagents upon transferring/deleting them you
get a total of 6 signal calls!!. Now it's just 3(when using `trans_to`)
and just 1 when using `remove_all/clear_reagents`. Need i say more no
## Changelog
🆑
fix: hydrophonics circuit component actually sets output level when
reagents are changed in the tray
refactor: refactors how code listens for reagent changes. Report bugs on
github
/🆑
## About The Pull Request
Makes it so strange geysers now say their name when scanned.
## Why It's Good For The Game
Should help make geysers actually worthwhile now that it's easier to
tell what they produce.
## Changelog
🆑
qol: Strange geysers now say in their name what they produce.
/🆑
## About The Pull Request
Stacking two lockers ontop of eachother and shoving someone into them
will result in them getting stuck in an open locker, with no way to get
out.
## Changelog
🆑
fix: You can no longer get stuck in stacked lockers
/🆑
