Skip to content

Upstream 2026-06-11#144

Closed
mass-bot[bot] wants to merge 102 commits into
masterfrom
upstream
Closed

Upstream 2026-06-11#144
mass-bot[bot] wants to merge 102 commits into
masterfrom
upstream

Conversation

@mass-bot

@mass-bot mass-bot Bot commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

🆑 MassMeta
add: Upstream 2026-06-11
/:cl:

TealSeer and others added 30 commits June 6, 2026 19:23
## About The Pull Request
Melbert has tasked me to handle fixing and cleaning up a few things from
#96236 after I merged it before they could review it a second time, plus
a few things I've noticed on my own (changing the name and desc is best
handled by the update_name and update_desc proc respectively, and soil
shouldn't process while inside trays).
…(#96376)

## About The Pull Request
Removes a check that checks if material_weight_mult is equal to 1 in
fish's apply_material_effects.
## Why It's Good For The Game
Fixes #96308
Also fixes #96357
## Changelog
:cl:
fix: Parthenogenesis no longer makes your material fish have null
weights
/:cl:
## About The Pull Request

The light mode colors for `span_green` are bright and hard to read,
whereas the dark mode ones are weirdly dark, so I swapped them.

<img width="289" height="79" alt="image"
src="https://github.com/user-attachments/assets/65a8f064-7ecb-461f-8d5f-4d85cf49ab97"
/>


## Why It's Good For The Game

Improve text contrast in light mode

## Changelog

idk
## About The Pull Request

Pretty simple one this time.

Cleans up pinpointer code, previously the ranges at which pinpointer
arrows determined how close you were to an object were hardcoded
numbers, now I've moved those numbers over to a set of variables so you
can determine what's close/medium/far.

Autodocs pinpointer variables and subtype variables as well.

Removed a functionally useless variable off of crew pinpointers, moving
from a boolean-`has_owner` to just checking against the assigned
`pinpointer_owner` mob.

Lastly, tweaked some of the numbers on the ventpointer, a pinpointer
purchasable by shaft miners for points. Namely, I've lowered it's
minimum range to 8 from 14, meaning that you can get closer before it
says that you've arrived at your vent, as before you could still be
completely off screen and be unable to find the vent. In addition, I
adjusted the close and medium range variables to be wider than the
standard range, since in practice using the ventpointer in-round tends
to just show a red arrow for the vast majority of the time you're using
it.

## Why It's Good For The Game

Pinpointer code improvements were mostly because I was in the area and
in theory, pinpointer code should be more flexible considering how much
of the game's core game-modes rely on pinpointers to function properly.

On ventpointers, these things are clearly meant to be somewhat
inaccurate, but due to having the distance values on pinpointers
hardcoded, It was previously impossible to ever even reach close range
on the vent before it claimed you had arrived. I've lowered the close
range value to be in the ballpark of a single screenwidth of tiles in
all directions, and adjusted the other colors so that you can get a
better idea if you've switched vent targets. As a result, the
ventpointer should be a more valuable investment as a direct result.

## Changelog

:cl:
balance: The mining ventpointer has been adjusted so that it can now
more accurately show the distance to the nearest vent, and will now
claim you've arrived if you're within 8 tiles away from a vent, down
from 14.
code: Several backend improvements to the pinpointer functionality and
adjustability.
/:cl:
…nce (#96369)

## About The Pull Request
This PR makes a few changes:
1. It makes audio respect max_range correctly. Due to the way we used
fall-off before, we would often get sounds that ended up going below 3
volume, due to an earlier PR, we made any sound below 3 volume not play.
This meant that if you had a sound wiht a max_range of 17, it would not
even play beyond 15~ range.

This change makes it so there's a min volume of 3 (changeable per
playsound use, but I havnt changed the default anywhere), and falloff
caps at this volume. This makes it so we always play at max_range still.
I reduced default sound range to 15 to compensate for this, which is
roughly what the distance would have been in the old system.

The sound curve now looks like this:
<img width="1322" height="861" alt="image"
src="https://github.com/user-attachments/assets/c11a02e7-877c-4467-bb10-129b3f59188b"
/>

The second change is that instead of using chebyshev distance, we now
use euclidean distance to determine the volume of sound.
The reason for this is that chebyshev distance does not respect
diagonals, which means a lot of tiles are treated as the same distance
which makes them sound the exact same too.
<img width="800" height="600" alt="image"
src="https://github.com/user-attachments/assets/b5e40f12-619a-42ad-94fb-85e7fef58adb"
/>

With Euclidean distance, we use the literal distance for diagonals,
which results in much more accurate falloff, and means you notice
falloff much better when walking past something

<img width="252" height="251" alt="image"
src="https://github.com/user-attachments/assets/a9bd5255-9207-4775-b3fb-1b8ca8a63bd3"
/>

BEFORE:


https://github.com/user-attachments/assets/1c327557-283c-49fc-9231-8425a29f7a83


AFTER:


https://github.com/user-attachments/assets/e7f88409-c2fc-4ba8-8dd9-3e23b2eec5c2


## Why It's Good For The Game

makes falloff more accurate to your position, which to me sounds better.
also it makes max_range actually do what it says; be the range at which
you can hear the sound.

## Changelog

:cl: CabinetOnFire
sound: Sound now makes use of euclidean distance for falloff
code: max_range on playsound now ensures the sound is audible up to that
range.
/:cl:
## About The Pull Request

`/datum/disease/proc/infect(mob/living/infectee, make_copy = TRUE)` does
NOT always represent the disease infecting someone.

If you pass `make_copy = TRUE`, the proc actually handles the *copy*
infecting the mob, rather than the disease itself.

(The issue here arises from `register_disease_signals` here being called
on the disease itself rather than the potential copy. )

This itself could(should) easily be fixed, by making a copy before going
into `infect`, but this is an easy fix in the meanwhile.

Fixes #96372

## Changelog

:cl: Melbert
fix: Fixed a bug where diseases wouldn't trigger their regular effects
when applied in certain contexts
fix: Fixed a bug where airborne diseases wouldn't spread via breathing
when applied in certain contexts
/:cl:
…d (#96381)

## About The Pull Request

Whenever an antag team is deleted, it wouldn't properly clear the `team`
var from its objectives - resulting in a hard delete.
## Why It's Good For The Game

Fixes a hard delete.
## Changelog
:cl:

/:cl:
… out of any material) (#96347)

## About The Pull Request
Allow carving blocks to be made by any material, instead of just rigid
materials.
## Why It's Good For The Game
<img width="612" height="70" alt="pride"
src="https://github.com/user-attachments/assets/afb5ed16-ba7a-4910-9b36-8fed8267536a"
/>

This allows for the construction of
Ice Statues (Hot Ice)
Beige Statues (Sand + Sandstone)
Snowpeople (Snow)
Origami Statues (Paper)
Cardboard (Cardboard)
REAL ghosts (Hauntium)
Meat Statue... 🤤🤤🤤🤤 (Meat)
(Not pictured) Pizzer Statue (Pizza)
Also more player expression + if you could make chairs and airlocks and
toilets and sinks and all that other shit out of these, why the hell NOT
a carving block!?
## Changelog
:cl:
balance: Carving blocks can be made out of any material now!
/:cl:
## About The Pull Request

We allow C&D to run at most 50 minutes as its hard timeout, so we should
have a matching timeout on the tests.

I'm open to lowering both of these, I do think 15 is far too small in
the case of hard deletes however, you want to be able to track those
down effectively and searching can take a while.
## About The Pull Request

I normally really don't like doing this but because this is so in the
weeds this is an alt pr.
Alt of #96366, I really don't want to add overhead to process_cell().

The issue here is when we request a reservation the turfs are empty()'d
which clears them out and places them in SSair's adjacent_turf recalc
queue (which will eventually cause an activation to clear out excited
groups).

We then immediately start maploading, which creates new, uninitialized
turfs (that remain in the queue because turf refs are based off position
instead of the actual datum). These unintialized turfs are able to
interact with the other, yet to be new()'d over turfs in the recalc
queue. This causes runtimes.

Later, while we initialize the turfs we loaded, we also have
interactions between initialized and uninitialized turfs, which also
causes runtimes.

The solution here is to prevent atmos processing in a loading template.
I do that here by first clearing out all relevant turfs from
atmos_adjacent_turf lists and deactivating them. We also have to clear
them from the recalc queue to prevent "fixing" this problem.

Then, after initialize is complete, we requeue them for recalcing, to
restore them to a workable state.

The underlying problem here is the logic of maploading is kind of
designed to run before everything else has initialized. It's something
we can dodge, but it will also show up in things that start processing
on initialize and expect their turf to immediately be ready for them. S
a bit of a mess.

Of note, it's technically possible for a turf to be initialized,
activate, and then attempt to process with an unitialized neighbor with
this solution. My gut fix for this would be using blocks_air to prevent
adjacent turfs from being recalculated until after InitializeAtoms is
finished, but that breaks turf/open/Initialize where we setup
gasmixtures, and I don't want to duplicate that code.

So we'll just bite the small risk of runtimes, they won't actually break
anything after all just make a bit of noise.
## Why It's Good For The Game

Closes #89649
This adds about 110ms of cost to loading the nukie station on my machine
(I used line by line macros around the two for loops), which is
significant but not huge, and it's cost that can be safely CHECK_TICK'd.
I think the cost of actually loading outweighs that significantly enough
(6.6s on my machine) that it's fine.

I prefer this solution to the alternative of adding guard checks to
process_cell because I do not want to add overhead to atmos code, and
also I don't like the idea that we cannot reliably prevent this (shuttle
code handles it effectively using blocks_air, as an example). Also, it
doesn't really resolve the uninitialized bit of this problem, which
isn't... good. Technically changes the math on share() too)
## About The Pull Request

simply adds a new unit test, `language_key_conflicts`, ported from my
work on monkestation.

it is exactly what it says on the tin - it ensures two languages do not
have the same exact key. i don't think that's an issue here, but better
safe than sorry.

## Why It's Good For The Game

more unit test coverage for subtle bugs that might be hard to realize is
always nice

## Changelog

No user-facing changes.
## About The Pull Request

Adds the Rapid Decoration Device and plastic plants and stones!

<div style="display:flex; gap:8px; align-items:center;">
<img width="92" height="93" alt="image"
src="https://github.com/user-attachments/assets/1c53d55f-6dd0-4841-8fb8-f46e5392421c"
/>
<img width="104" height="93" alt="image"
src="https://github.com/user-attachments/assets/0c86eac0-cc43-4587-a1c4-e73c894ab674"
/>
<img
src="https://github.com/user-attachments/assets/d99fef71-31de-4059-940a-73f64ed8660e"
width="415" height="93" alt="image" />
</div>

<img width="830" height="597" alt="image"
src="https://github.com/user-attachments/assets/e51330a3-58fb-428b-b002-323192f52f2e"
/>
<img width="713" height="293" alt="image"
src="https://github.com/user-attachments/assets/45a4f037-4153-461b-84d1-d1c923dcf1a9"
/>

<br>
<br>
Plastic plants are very cheap to make but at the same time are very
fragile (20 integrity points). They cannot be deconstructed by wrenching
(only by destroying them or using a RDD to suck them in) and yield no
resources.
<br>

<br>
The RDD is available in the service protolathe roundstart.
<br>
<br>
<img width="293" height="120" alt="image"
src="https://github.com/user-attachments/assets/69506d34-c309-4c6e-8658-8e0d22816f91"
/>

## Why It's Good For The Game

RDD is a great way to decorate the station or your passion projects
without having to hunt down and dig out decorative flora piece by piece.
I think this will also pair greatly with
tgstation/tgstation#96345

## Changelog
:cl:
add: Added fake plastic plants to be used for decoration
add: RDD: Rapid Decoration Device is now available for the service
department
/:cl:

---------

Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
tgstation-ci Bot and others added 23 commits June 11, 2026 01:14
## About The Pull Request

Forgot an argument, direction became source

## Why It's Good For The Game

Works

## Changelog
:cl:

fix: Blood spraying from hitting existing wounds works

/:cl:
## About The Pull Request

No type check prior

## Why It's Good For The Game

Runtime

## Changelog
:cl:

fix: fixed a runtime when trying to pull a turf

/:cl:
## About The Pull Request

0 is apparently truthy to a ternary, who knew. 

Also deletes every value return in blob code where that value is never
used, even where it is not currently causing a runtime

Also shuffles around the upgrading order to save space, and prevents
wasting 15 points upgrading a reflecting blob into a reflecting blob

also one letter vars

## Why It's Good For The Game

Runtime

Waste of time

Waste of points

Waste of time

## Changelog
:cl:

fix: fixed runtime when trying to upgrade a blob, & fixed wasting points
upgrading a reflective blob into a reflective blob

/:cl:
## About The Pull Request

Doesn't necessarily have a pinned ID

## Why It's Good For The Game

Runtime

## Changelog
:cl:

fix: Corgis no longer runtime when trying to open doors without an ID

/:cl:
## About The Pull Request

<img width="345" height="347" alt="dreamseeker_g3fZveerSI"
src="https://github.com/user-attachments/assets/bb80332e-8392-4cc4-b754-bf3075da60fb"
/>

New rocks are noticeably larger and old maptext offsets resulted in
depth numbers being partly covered

## Changelog
:cl:
fix: Fixed debug overlays on new biome rocks on lavaland
/:cl:
## About The Pull Request
The surgical drill used the circular saw sound when it should have used
the drill sound instead.

## Why It's Good For The Game
Better sound.

## Changelog
:cl:
sound: Add drill sound to surgical drill
/:cl:
## About The Pull Request
This adds the typing/keypad sound used on many consoles when you
interact with a secure safe.

## Why It's Good For The Game
Better sounds.

## Changelog
:cl:
sound: Add keypad sounds to secure safes
/:cl:
## About The Pull Request
It plays a valve-twisting sound when a portable canister is
opened/closed.

## Why It's Good For The Game
Sound improvements.

## Changelog
:cl:
sound: Add valve sound to portable canisters
/:cl:
## About The Pull Request

Rewrite the big `attackby` for security cameras to use
`item_interaction` and distinct `_act` procs, also turns the big
clusterfuck for pressing notes up to cameras into a slightly less
clusterfuck proc

## Why It's Good For The Game

Clean code

## Changelog
:cl:
refactor: security camera construction/item interaction has been
rewritten, report any weirdness
/:cl:

---------

Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
…ed on someone's manifest record (#96429)

## About The Pull Request

Buckle up for this one, folks, this is one hell of a corner case.

When a `mob/living/carbon/human/species` with `use_random_name` set to
TRUE changes species, it calls `fully_replace_character_name`. When
`fully_replace_character_name` is called with a non-null `oldname`
argument, it searches for a manifest record whose listed name is
`oldname`, and changes the name on that record to the new name.

Changing a monkey's name to the name of someone on the manifest, such as
with a dna injector, means that their `oldname` is the same as a record
on the manifest. As a result, if their species is changed in any way,
such as disabling the monkified mutation, the record on the manifest is
changed to the new randomly generated name for the monkey.

This PR simply changes the call to `fully_replace_character_name` in
`mob/living/carbon/human/species/set_species` to not pass in an
`oldname`.

## Why It's Good For The Game

Fixes #96399

## Changelog

:cl:
fix: Changing the species of most monkeys, whose names were changed to
those of individuals on the manifest, will no longer cause the names on
those individuals' records to be changed to the name the monkey ends up
with.
/:cl:
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.