## 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
/🆑
## About The Pull Request
What it says on the tin. Also updates the theft objective appropriately.
## Why It's Good For The Game
@MrMelbert asked me to do this, and I'm happy to oblige.
Firstly, the HoS has a signature gun as it is. His X-01 Multiphase.
Having another weapon in the form of the shotgun kind of steps on the
toes of that weapon's presence, and clutters his arsenal somewhat. The
HoS, as is, has the means of gearing for alternative equipment if
needed, but let's keep it somewhat slim for weapons.
Secondly; it feels more appropriate as a riot suppression weapon. And
the warden puts down riots and brig invasions. He is the CQB guy after
all, he should have a shotgun. It's a bit of an identity thing and a
functionality thing. Of course, he could just get a riot shotgun (so can
the HOS in this instance), but I think having a special one does have
impact from a purely aesthetics point of view, gives more of a feeling
of 'ownership' over the shotgun (which matters for the sake of whether
people are determined as overgearing or not), as well as telegraphing
what should be his combat strategy for him more clearly.
No, there is no option where they both have shotguns. Don't bother
asking.
## About The Pull Request
Swapped direct loc checks with recursive contents to prevent extreme
bluespace bodybag cheese + removed self comsig reg and fixed lowercase
you
## Changelog
🆑
fix: Fixed rolling table being able to carry an infinite amount of
dwarves
grammar: Improved rolling table grammar
/🆑
## About The Pull Request
Added a helper to check if something is a tile made out of iron, and
changed all plating placement code to use it.
## Why It's Good For The Game
Its very easy to misclick or get confused and make the wrong type of
tile in the crafting menu, and since material tiles made from iron
aren't a subtype of ***iron*** tiles, you won't be able to use them to
make plating. Space already accounts for this, but lattice, chasms,
openspace and foam plating do not.
## Changelog
🆑
qol: Iron material tiles can now be used to tile lattice to make plating
/🆑
## About The Pull Request
- Fixes#88657
When you begin resisting you can't resist again till either the breakout
was successful or failed. This also lead to the shake animation being
reapplied multiple times causing additional shaking on top of it already
shaking
## Changelog
🆑
fix: breaking out of a closet won't spam chat or shake like it's having
a seizure
/🆑
## About The Pull Request
Was just scrolling through the Paradise github since they seem to have
more work done for 516 to see if there's anything I can port over, found
this and thought why not.
Ports parts of https://github.com/ParadiseSS13/Paradise/pull/25105
Specifically, updaing all hrefs to use the internal ``byond://``, and
adding it to grep.
## Why It's Good For The Game
More work towards 516.
## Changelog
Nothing player-facing.
## About The Pull Request
This change make the lockers "electronics" weaker to the spear,
restoring its ability to destroy lockers. While this functionality was
not originally intended (throwing spears on lockers) ( #88141 ), it has
been present for so long that it has effectively become a feature. This
pull request rework that feature by making the spear do damage by
hitting lockers in melee.
https://github.com/user-attachments/assets/67058342-57e2-4670-9c68-df4c3b6d6193
## Why It's Good For The Game
Restoring the spear's ability to destroy lockers maintains its previous
utility and aligns with player expectations, preserving and reworking
feature that has become a staple of gameplay and lower the burden on
antagonist to open security or command lockers.
## Changelog
🆑 UnokiAs
add: Make spears able to break open lockers in melee.
/🆑
## About The Pull Request
Rather than checking for object layer if we can clean something, has a
trait which accomplishes this
This better allows us to pick and choose what objects we want to clean
when mopping
Note: I didn't apply the trait to everything it previously affected
Currently, it cleans stuff like pipes and plumbing, which I deemed not
necessary to carry over since they can't get dirty anyways
I can re-add this if desired though
Fixes#88445Fixes#88150
## Changelog
🆑 Melbert
fix: Gibs get bulk cleaned if you clean the turf again
refactor: Changed how things determine "I can be bulk cleaned if I clean
the turf underneath me", let me know if you notice anything not getting
bulk cleaned or weird things getting bulk cleaned
/🆑
## About The Pull Request
This is the first PR in a series attempting to modernize our damage and
armor, both from a code and a gameplay perspective. This part implements
unique attack animations, adds alternate attack modes for items and
fixes some minor oversights.
Items now have unique attack animation based on their sharpness - sharp
items are now swung in an arc, while pointy items are thrust forward.
This change is ***purely visual***, this is not swing combat. (However,
this does assign icon rotation data to many items, which should help
swing combat later down the line).
Certain items like knives and swords now have secondary attacks - right
clicks will perform stabbing attacks instead of slashing for a chance to
leave piercing wounds, albeit with slightly lower damage - trying to
stick a katana through someone won't get you very far!
https://github.com/user-attachments/assets/1f92bbcd-9aa1-482f-bc26-5e84fe2a07e1
Turns out that spears acted as oversized knives this entire time, being
SHARP_EDGED instead of SHARP_POINTY - in order for their animations to
make sense, they're now once again pointy (according to comment,
originally they were made sharp because piercing wounds weren't very
threatening, which is no longer the case)
Another major change is that structure damage is now influenced by armor
penetration - I am not sure if this is intentional or not, but attacking
item's AP never applied to non-mob damage.
Additionally, also fixes an issue where attack verbs for you and
everyone else may differ.
## About The Pull Request
- Removed unused vars `click_mods`, `lean_check` & `same_turf` from the
leaning component. Walls & windows the only two atoms that support
leaning don't use these vars so its unused code
- Leaning component now starts leaning inside its `Initialize()` proc,
which means we don't have to call `base_mouse_drop_handler()` manually
- Because of point 2 we can now properly lazy load the leaning component
via `LoadComponent()` proc instead of keeping track of a boolean var to
check if we added the component or not.
Just cleaner & lesser code overall
## Changelog
🆑
code: improved code for leaning
/🆑
## About The Pull Request
"If GAGS is such a good system, why isn't there GAGS 2?" - Sun Tzu
GAGS is very neat but it has one glaring issue: it needs sprites to be
greyscaled in advance to be used. On the other hand we have color
matrices, but they're hard to use and even harder to get good results
from. The logical solution grew out of a discord argument about colors
this morning after @LemonInTheDark decided to toy around with HSL
matrices using filters on live servers.
This PR implements Color Transition Filters as an additional option for
atom colors - passing a transition filter matrix into
``add_atom_colour`` will "recolor" the atom into the passed color by
using an HSL filter (since color only supports RGB values and matrices).
Normal color matrices are now also supported in atom colors, in case
anyone needs to use them there. ``color_transition_filter`` has 2 modes:
``SATURATION_MULTIPLY`` which only changes the hue and shifts saturation
of the original icon, and ``SATURATION_OVERRIDE`` which changes
saturation and light values to more correctly fit the passed color.
Multiply mode does a far better job at recoloring clothing or objects
with obvious highlights, but fails to color pale or white objects, while
Override mode is closer to what we have right now (just doesn't produce
rancid blobs of color nearly as much)
Here are some examples of colored clothes, mechs, items and tiles using
the new system.
Green RD? Sure.
Atmos MODsuit colored with a speed potion
Why override mode exists in the first place
Aftermath of a colorful reagent grenade.
As you can see, the colors are far brighter and significantly less
acidic, since they're no longer just used as multipliers for existing
colors but instead shift the palette of the sprite towards themselves.
In order to bypass the main downside of "default" Multiply mode,
spraycans have received a new right click function "coat with paint",
which will color the item using the Override mode. Left Click mode lost
its coloring restrictions (RMB still has them), and color
sampling/prosthetic recoloring has been moved to Ctrl Click instead.
Here's the full list of all systems/items that now use color transition
filters:
* Drying items
* Deep frying items
* Slime blueprints/potions/coloring crossbreeds
* Colorful reagent
* Spraycans
* Paint buckets
## Why It's Good For The Game
Our coloring system is ***really*** bad, to the point where we're
preventing players from using any dark colors because item icons become
unintelligible when colored into them.
## Changelog
🆑 SmArtKar, LemonInTheDark
add: Changed how spraycans color items - "old" mode is still availible
via right click.
refactor: Refactored how some items and effects color things so that
they look prettier.
/🆑
## About The Pull Request
This adds a crate to medical holodeck sim with a full set of human
organs inside a freezer containing:
- heart
- lungs
- eyes
- ears
- tongue
- liver
- stomach
- appendix
##### (And yes, a holodeck organ can fade away while it's still inside
someone causing them to suffer organ loss)
## Why It's Good For The Game
Immersion.
## Changelog
🆑
add: Add medical human organ crate emergency medical holodeck simulation
/🆑
## About The Pull Request
Looks through calls to `receive_damage` and replaces them with calls to
`apply_damage`
`receive_damage` is a gross to use internal proc that doesn't take into
account physiology (damage modifiers) or even update the mob's sprite
when taking damage
It should be avoided many uses - `apply_damage`, in fact, can take a
bodypart as a target, and is overall a lot easier and more ergonomic to
use.
"So what are valid uses of it?"
- Apply damage itself, and similar direct-damage procs
- Ensuring you deal an exact amount of damage to a bodypart
- Damaging a limb with no owner
## Changelog
🆑 Melbert
refactor: A ton of things now use the more correct method of applying
damage to you. Which means they will correctly factor in damage
modifiers and are less likely to break your sprite. Some examples
include embedded objects jostling around, chiropractice, and tackling a
wall. Report any oddities, such as extreme damage or bodyparts being
wrongly affected.
fix: Having acid splashed on your face may now disfigure you and make
you bald, as it once did three years ago.
fix: Itchy heretic trauma now better checks if the bodypart is covered
or not before determining if you should itch.
fix: "Repair Puncture" logs no longer mistakenly report you are
"Incising burned flesh"
/🆑
## About The Pull Request
Commission plaques were outdated, so they needed updating. This adds
Wawa's merge date, which was not present, moves Northstar's to the
removed station list, and adds one for Nebulastation. I also
alphabetized the current map list to be in line with the removed list.
No map edits were made.
## Why It's Good For The Game
Just keeping things up to date
## Changelog
🆑
spellcheck: Station commission plaques (the gold ones that have the date
they were added) have been updated, adding Nebula's, fixing Wawa's, and
decommissioning Northstar's.
/🆑
## About The Pull Request
the dotted color board was missing a color for the 10th digit, and
orange and brown were not valid byond colors (damn you ghommie)
fake scrubbers and vents use the correct layer and plane
you may no longer deconstruct indestructible windows
you can no longer push indestructible grilles and robust windows if you
have a strong move force
step teleporters may not teleport abstract objects or mirage holders
(due to init shenanigans this sometimes teleported a mirage holder
messing the visuals up)
## Why It's Good For The Game
bug bad also i didnt make these bugs ok
## Changelog
🆑
fix: fixed the museum password puzzle (to the cafeteria), and the
scrubbers and vents there now look correctly (also fixed a rare visual
bug)
fix: it is now harder to bypass indestructible windows and grilles
(those are placed there for a reason, you know!)
/🆑
## About The Pull Request
Last night I was experimenting with hooking up different chemicals to a
shower and discovered that blood didn't really do anything other than
have red mist and particles. Your characters clothes were still cleaned.
The mood boost was still happy. So I reworked it a bit.
Blood now:
- Gives a negative mood, disgust, and status effect when showering with
it (unless you are morbid, evil, or undead, then it's considered
positive)
- Has an icon alert for bloody showers
- Covers a mob's clothing with blood when showering (or any objects on
the tile)
- Tossing or spraying a container full of blood now covers objects/mobs
in blood
- The revenant defile spell now affects showers by removing all water
recyclers and reagents that gets replaced with blood
Showers now:
- Require 70% of water to clean and get mood/status effects
- Require 70% of blood to get mood/status effects
- Require 20% of radioactive reagents to stop radiation removal effects
So it's possible to have a clean water shower that is secretly
radioactive. Since radioactive reagents do nothing on `TOUCH`, all this
achieves is preventing the water from washing off the radiation.
I did have to refactor some of the reagent code to support method types
for objects since I was experiencing hazmat issues when I was testing.
Whenever I would inject blood from a syringe into a beaker, it would
cover the beaker in blood on the outside. This would have been extremely
hazardous for viruses. So I needed to make sure we are only applying it
to the methods for `VAPOR|TOUCH`
Also improved the mood typecasting for owner to allow checking of mob
biotypes. (so we can check `UNDEAD` for mood)
## Why It's Good For The Game
Blood effects and interactions are now more consistent. The code for
objects is refactored to support method interactions with reagents.
Evil/Morbid people now get some unique interactions that fit their
theme. Last we get a cool new ability to let revenant's make their
defiled areas something out of a horror movie.
## Changelog
🆑
add: The revenant defile spell now affects showers by removing all water
recyclers and reagents that gets replaced with blood.
add: Showering in clean water (+70%) results in positive
mood/regen/stamina effects. It will wash off the mob.
add: Showering in dirty water results in negative mood effects and
disgust. It will NOT wash off the mob.
add: Showering with radioactive reagents (+20%) results in the
preventing the shower from washing off the radiation.
add: Showering in blood (+70%) results in severe negative mood effects
and disgust. (unless you are morbid, evil, or undead then it's
considered positive) It will cover the mob in blood.
add: Water effects that interact with a mob from touch or vapor
(showering/spray bottles/etc.) will now heal sleep, unconsciousness,
confusion, drowsiness, jitters, dizziness, and drunkenness.
fix: Fix bloody showers not covering objects in blood.
fix: Tossing or spraying a container full of blood now covers
objects/mobs in blood
fix: Fix wrong status effect for watery tile
image: Add new alert icons for bloody/dirty showers
code: Refactored some expose_obj reagent code to support method types.
code: Improved mood typecasting for owner to allow checking of mob
biotypes.
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
`boldannounce` is NOT for use ICly it's only for OOC stuff. `bolddanger`
is identical it just doesn't carry the same baggage
## Changelog
🆑 Melbert
fix: Stuff like the SM exploding will no longer output to your OOC tab
/🆑
## About The Pull Request
Caused by:
- https://github.com/tgstation/tgstation/pull/88048
Trying to use the fireplace would result in runtimes and the smoke
particles not triggering.
Even though the runtime is fixed, the new particle changes in #88048
broke the pixel offsets. While I was testing, anytime I tried switching
a pixel offset it would update all fireplaces. I tried to limit it to
add the shared particle id to `"fireplace_[dir]"` so that it would only
apply to the objects in that direction but I couldn't get it to work. I
would guess this also affects a lot of other objects that have particle
pixel offsets.
Runtime is fixed. Particle offsets are still broken.
## Why It's Good For The Game
Fireplaces no more runtime.
## Changelog
🆑
fix: Fix fireplace particles runtimes.
/🆑
## About The Pull Request
~~Kept you waitin huh!~~
The projectile refactor is finally here, 4 years later. This PR (almost)
completely rewrites projectile logic to be more maintainable and
performant.
### Key changes:
* Instead of moving by a fixed amount of pixels, potentially skipping
tile corners and being performance-heavy, projectiles now use
raymarching in order to teleport through tiles and only visually animate
themselves. This allows us to do custom per-projectile animations and
makes the code much more reliable, sane and maintainable. You (did not)
serve us well, pixel_move.
* Speed variable now measures how many tiles (if SSprojectiles has
default values) a projectile passes in a tick instead of being a magical
Kevinz Unit™️ coefficient. pixel_speed_multiplier has been retired
because it never had a right to exist in the first place. __This means
that downstreams will need to set all of their custom projectiles' speed
values to ``pixel_speed_multiplier / speed``__ in order to prevent
projectiles from inverting their speed.
* Hitscans no longer operate with spartial vectors and instead only
store key points in which the projectile impacted something or changed
its angle. This should similarly make the code much easier to work with,
as well as fixing some visual jank due to incorrect calculations.
* Projectiles only delete themselves the ***next*** tick after impacting
something or reaching their maximum range. Doing so allows them to
finish their impact animation and hide themselves between ticks via
animation chains. This means that projectiles no longer disappear ~a
tile before hitting their target, and that we can finally make impact
markers be consistent with where the projectile actually landed instead
of being entirely random.
<details>
<summary>Here is an example of how this affects our slowest-moving
projectile: Magic Missiles.</summary>
Before:
https://github.com/user-attachments/assets/06b3a980-4701-4aeb-aa3e-e21cd056020e
After:
https://github.com/user-attachments/assets/abe8ed5c-4b81-4120-8d2f-cf16ff5be915
</details>
<details>
<summary>And here is a much faster, and currently jankier, disabler
SMG.</summary>
Before:
https://github.com/user-attachments/assets/2d84aef1-0c83-44ef-a698-8ec716587348
After:
https://github.com/user-attachments/assets/2e7c1336-f611-404f-b3ff-87433398d238
</details>
### But how will this affect the ~~trout population~~ gameplay?
Beyond improved visuals, smoother movement and a few minor bugfixes,
this should not have a major gameplay impact. If something changed its
behavior in an unexpected way or started looking odd, please make an
issue report.
Projectile impacts should now be consistent with their visual position,
so hitting and dodging shots should be slightly easier and more
intuitive.
This PR should be testmerged extensively due to the amount of changes it
brings and considerable difficulty in reviewing them. Please contact me
to ensure its good to merge.
Closes#71822Closes#78547Closes#78871Closes#83901Closes#87802Closes#88073
## Why It's Good For The Game
Our core projectile code is an ungodly abomination that nobody except
me, Kapu and Potato dared to poke in the past months (potentially
longer). It is laggy, overcomplicated and absolutely unmaintaineable -
while a lot of decisions made sense 4 years ago when we were attempting
to introduce pixel movement, nowadays they are only acting as major
roadblocks for any contributor who is attempting to make projectile
behavior that differs from normal in any way.
Huge thanks to Kapu and Potato (Lemon) on the discord for providing
insights, ideas and advice throughout the past months regarding
potential improvements to projectile code, almost all of which made it
in.
## Changelog
🆑
qol: Projectiles now visually impact their targets instead of
disappearing about a tile short of it.
fix: Fixed multiple minor issues with projectile behavior
refactor: Completely rewrote almost all of our projectile code - if
anything broke or started looking/behaving oddly, make an issue report!
/🆑
## About The Pull Request
Closes#83370
Converted most cases where we could benefit from using shared particles
(aka when there's probably more than 3 uses of that particle in a round)
to use the new shared particle system. Should provide significant
clientside performance in particle-heavy areas like botany (or sometimes
kitchen)
## Changelog
🆑
refactor: Converted most common particle sources to use our new pooling
system.
/🆑
