## 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
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 PR should fix the problem of small previews in TGUI once and for
all (I hope).
What was causing it? Because TGUI takes a long time to open, that's why
previews were generated broken (small).
On Byond 515 this problem was not so noticeable as the interfaces opened
faster, but with the release of 516 it became much worse.
Previews were generated inside a window that was not yet open, so the
scale was broken, sometimes the window would open before the preview was
done and sent, usually with small interfaces, or when reopening.
I'm not very good at working with signals, and to tell the truth this is
my second experience with them, so I hope I did it right.
## Why It's Good For The Game
No more small map previews
<details> <summary> Video </summary>
https://github.com/user-attachments/assets/834f3820-cc6a-4f65-90e5-d6bb2a118bcf
</details>
## Changelog
🆑
fix: Fixed small character preview, color matrix preview, mech preview,
and other previews with uses ByondUI map
/🆑
---------
Co-authored-by: Gaxeer <44334376+Gaxeer@users.noreply.github.com>
## About The Pull Request
MODsuits now calculate their slowdown by querying modules by sending a
signal on themselves instead of having modules try and keep up with
control unit's speed updates (which broke in a fabulous fashion after
MODsuits were allowed to deploy by piece)
Also added a separate trait to prevent objects from being speed
potion-ed to combat stabilized red crossbreed issues, and removed a
duplicate list helper (40 lines down in the same file lol)
Closes#89979Closes#90036
## Changelog
🆑
fix: MODsuits should now be affected by stabilized red crossbreeds
fix: MODsuit slowdowns should no longer behave weirdly with ash
accretion/magboots/armor booster modules.
refactor: Refactored MODsuit slowdown calculations to be query-based
instead of modules directly modifying part speed values.
/🆑
## 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
When the device of a modsuit module (eg foam mister) is the first thing
to be deleted, it causes a del loop runtime. Chain is:
- device qdel, hasn't yet run destroy() which would normally move the
device to nullspace
- signal runs on_device_deletion, destroys the module
- module destroy(), calls parent which deletes contents, including the
still-deleting device
Fixed by moving device to nullspace in on_device_deletion
## Changelog
N/A
## About The Pull Request
Completely refactored how client colors are handled. Now they're similar
to traits, having a source associated with them. Instead of adding and
removing by strict type (which makes client colors prone to getting
duplicated and not cleaned up) you remove a filter associated with a
specific source. Adding another client color with the same source as an
already existing one will replace the existing one if its of a different
type, or do nothing if they're the same (unless force is set to TRUE).
Client colors can also force filter splitting, putting all colors that
come before them, themselves, and all colors after them into separate
filters - this is useful to prevent mixing in filters which are supposed
to remove a certain color.
<details>
<summary>Example of how Perceptomatrix and nightmare vision goggles
combined before this PR:</summary>
And this is after, as you can see nightmare vision effect's red is only
slightly tinted by perceptomatix instead of being literally halved.
</details>
Additionally, added support for custom filters (and not just colors) to
client color code to allow us to work with more colorspaces.
Also fixed weird blindness behavior, so this also
Closes#89787
## Why It's Good For The Game
Makes code less ass to work with, fixes weird color mixing, etc.
## Changelog
🆑
fix: Fixed perceptomatix helmet allowing you to see even when
unconscious
refactor: Refactored how client colors are handled, ensuring that
certain effects like nightmare goggles don't disappear when another
vision-affecting piece of clothing is worn.
/🆑
## About The Pull Request
fixestgstation/tgstation#90064
also "fixes" the MODsuit UI for the glitch mod not being cyber terminal
green (like how it is for the UI popups. this is kind of garish though.
i'm willing to undo this) (the code seems to indicate it was supposed to
be like this but then it wasn't)
also fixes the gauntlets' right-facing sprite being one tile off
armor booster off
armor booster on
fixes extended to dark paladin mod
visor becomes red when booster active
## Why It's Good For The Game
drip check.
## Changelog
🆑
fix: The Cyber Tac Glitch MODsuit now has appropriately offset
gauntlets.
fix: The Cyber Tac Glitch MODsuit now has visor overlays instead of the
menacing white void. Red eyes, take warning (because that's when the
armor booster is active).
fix: The Cyber Tac Glitch MODsuit's interface theme is now an
appropriately terminal-esque.
fix: Dark Paladin MODsuits from the Dead Money bundle are no longer
menacingly white.
fix: Armor boosters in MODsuits in general are no longer menacingly
white voids.
/🆑
---------
Co-authored-by: Hatterhat <Hatterhat@users.noreply.github.com>
## About The Pull Request
Currently patches are a subtype of pills, and while they have the
``dissolveable`` var set to FALSE, barely anything checks it (because
people don't expect patches to be pills in disguise) so we end up
patches being dissolveable and implantable, which is far from ideal.
Both have been moved into an ``/obj/item/reagent_containers/applicator``
class, which handles their common logic and helps handling cases where
either one fits. As for gameplay changes:
* Pills no longer dissolve instantly, instead adding their contents to
your stomach after 3 seconds (by default). You can increase the timer by
dropping sugar onto them to thicken their coating, 1s per 1u applied, up
to a full minute. Coating can also be dissolved with water, similarly
-1s per 1u applied. Pills with no coating will work like before.
* Patches now only take half as long to apply (1.5s), but also slowly
trickle in their reagents instead of instantly applying all of them.
This is done via embedding so you could theoretically (if you get lucky)
stick a ranged patch at someone, although they are rather quick to rip
off. The implementation and idea itself are separate, but the idea for
having a visual display has been taken from
https://github.com/Monkestation/Monkestation2.0/pull/2558.
* In order to support the new pill mechanics, stomachs have received
contents. Pills and items that you accidentally swallow now go into your
stomach instead of your chest cavity, and may damage it if they're
sharp, requiring having them surgically cut out (cut the stomach open
with a scalpel, then cauterize it to mend the incision). Or maybe you
can get a bacchus's blessing, or a geneticist hulk to gut punch you,
that may also work. Alien devour ability also uses this system now. If
you get a critical slashing wound on your chest contents of your cut
apart stomach (if a surgeon forgot to mend it, or if you ate too much
glass shard for breakfast) may fall out. However, spacemen with the
strong stomach trait can eat as much glass cereal as they want.
Pill duration can also be chosen in ChemMaster when you have a pill
selected, 0 to 30 seconds.
## Why It's Good For The Game
Patches and pills are extremely similar in their implemenation, former
being a worse version of sprays and pills, with only change being that
pills cannot be applied through helmets while patches and sprays ignore
both. This change makes them useful for separate cases, and allows
reenactment of some classic... movie, scenes, with the pill change. As
for stomach contents, this was probably the sanest way of implementing
pill handling, and everything else (item swallowing and cutting stomachs
open to remove a cyanide pill someone ate before it dissolves) kind of
snowballed from there. I pray to whatever gods that are out there that
this won't have some extremely absurd and cursed interactions (it
probably will).
## Changelog
🆑
add: Instead of dissolving instantly, pills now activate after 4
seconds. This timer can be increased by using a dropper filled with
sugar on them, 1s added per 1u dropped.
add: Patches now stick to you and slowly bleed their reagents, instead
of being strictly inferior to both pills and sprays.
add: Items that you accidentally swallow now go into your stomach
contents.
refactor: Patches are no longer considered pills by the game
refactor: All stomachs now have contents, instead of it being exclusive
to aliens. You can cut open a stomach to empty it with a scalpel, and
mend an existing incision with a cautery.
/🆑
## About The Pull Request
#89619 introduced a MOB_MINING biotype which allows us to get rid of
jank that the ismining() macro was. This fixes soulscythes, cursed
katanas, mining bombs, strongarm implants and junk hunter bullets not
getting their buffs against a good chunk of mining fauna.
Closes#89597
## Why It's Good For The Game
You'd expect items explicitly designed against fauna to actually fare
well against it.
## Changelog
🆑
fix: Fixed most mining mobs being unaffected by additional damage
against them
/🆑
## About The Pull Request
This PR tackles our piss-poor item action handling. Currently in order
to make an item only have actions when its equipped to a certain slot
you need to override a proc, which I've changed by introducing an
action_slots variable. I've also cleaned up a ton of action code, and
most importantly moved a lot of Trigger effects on items to do_effect,
which allows actions to not call ui_action_click or attack_self on an
item without bypassing IsAvailible and comsigs that parent Trigger has.
This resolves issues like jump boots being usable from your hands, HUDs
being toggleable out of your pockets, etc. Also moved a few actions from
relying on attack_self to individual handling on their side.
This also stops welding masks/hardhats from showing their action while
you hold them, this part of the change is just something I thought
didn't make much sense - you can use their action by using them in-hand,
and flickering on your action bar can be annoying when reshuffling your
backpack.
Closes#89653
## Why It's Good For The Game
Makes action handling significantly less ass, allows us to avoid code
like this
```js
/obj/item/clothing/mask/gas/sechailer/ui_action_click(mob/user, action)
if(istype(action, /datum/action/item_action/halt))
halt()
else
adjust_visor(user)
```
## About The Pull Request
Closes#89635
Ugly solution but this is the best we can have until full 516 support
with animation tags.
## Changelog
🆑
fix: Sphere transform module no longer makes you spin permanently
/🆑
## About The Pull Request
MODSuits now slow you progressively as parts are deployed, and not at
all when no parts are deployed.
Previous to this change MODsuits would slow you _more_ for having a part
not deployed than for having it deployed and powered, meaning you would
be slower using it as a backpack than you would be when using it as a
suit. This leads to people typically taking it off entirely and holding
it in their hands instead of wearing it.
## Why It's Good For The Game
We talked about this in the coderbus meeting and the general reasoning
is;
- We want people to use MODsuits for the utility they provide. It's good
when people think these items are desirable and ask the roboticist to
make one for them.
- MODsuits being slower when unpowered makes sense but is _mostly_ just
that way for flavour reasons.
- Moving slower is (perhaps unintuitively?) one of the strongest
detriments we have in the game for using something.
- MODsuits when used as backpacks are _already_ worse than a standard
backpack (less storage space unless complexity is dedicated to increase
it again) and it's not necessarily clear that they need an additional
downside.
- It feels odd to be penalised _more_ strongly penalised when just
wearing a backpack and not benefiting from any utility aspect of the
suit than you are when actively benefiting from having the suit.
- It also feels odd to be penalised at all for having it while not
benefiting from it.
- The fact that they have a deployment time already reduces their
effectiveness in terms of being "snapped" on and off in response to loss
of atmosphere.
- The "juggling" behaviour that players resort to when they can't just
wear their suit as a backpack (swapping between a held backpack and a
held modsuit control with keybindings) is the kind of powergaming trick
I don't really like but is reasonably easy to do in order to bypass the
downside anyway, removing this removes any need to train players to do
this.
- Personally I feel that if people are wearing their MODsuit undeployed
while wandering around the station that's actually preferable to me than
if they had it deployed full-time, which is what they are more likely to
be doing if leaving it undeployed makes them slower (even if the
undeployed speed was the same as the deployed speed). At that point,
they might as well simply have it powered in order to benefit from being
atmospherics-proof and deal with having to charge it every so often.
**Doesn't this just make a MODsuit into a better backpack?**
No, it has lower capacity.
A standard MODsuit storage has a max weight capacity of 15 split across
up to 7 items.
A regular backpack has a max weight capacity of 21 split across up to 21
items (significantly more granularity).
**Won't this make people wear MODsuits all the time?**
Apart from ones that you get with your job, the Roboticist only starts
with a handful of mod cores to make more suits out of.
If we achieved even 1/3rd crew saturation on a busy round that would
mean a significant use of cargo to acquire more cores, which is a design
goal. I think the idea that it would reach total crew saturation is
basically unthinkable, we already limit the number of suits that can
exist at once via cargo.
Also, most suits with good utility _still_ make you slower _when
deployed_ so any time you are actually benefiting from its utility you
are experiencing a drawback.
## Changelog
🆑
balance: MODSuit parts now slow you only when deployed, regardless of
whether they are sealed.
balance: MODSuit parts no longer slow you when they aren't deployed.
/🆑
## 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
Fixes https://github.com/tgstation/tgstation/issues/87345
This adds a new item trait, `TRAIT_NO_WORN_ICON`, which is exactly what
it says on the tin - the worn overlay for said item will not be added
when the trait is present, so we give it to items hidden by the hood.
I also refactored the `EXAMINE_SKIP` item flag into
`TRAIT_EXAMINE_SKIP`.
## Why It's Good For The Game
stealth thing having an obvious sprite tell is bad. bugfix good.
## Changelog
🆑
fix: Void Cloaks now properly hide blades and such in the suit storage
from the wearer's sprite.
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## About The Pull Request
Originally, this module could be activated while the core was inactive.
Now, it doesn't because it needs you to deploy the vast majority of your
modsuit even while inactive. Kind of lame.
This corrects that so you can still deploy your firearm without the suit
being more or less deployed.
## Why It's Good For The Game
Looks like a copy-paste job to me. Or not understanding what this module
was. Hard to say.
## Changelog
🆑
fix: Allows MOD holsters to once again activate while the modsuit is
inactive and undeployed.
/🆑
## About The Pull Request
Springlocks no longer trigger when you only have a back piece deployed,
only damages bodyparts covered by deployed pieces, and prevents you from
retracting them when it's been set off
Closes#89218
## Changelog
🆑
fix: Springlock MODule now only activates when you have at least a
single sealed piece
fix: Springlock MODule no longer damages bodyparts not covered by your
MODsuit
/🆑
## About The Pull Request
Fixes tether stacking via beacons, you can freely cut your tether while
moving, and cutting/snapping MODsuit tethers now also snaps the beacon
they're connected to if said beacon was generated by a MODsuit
projectile. Retracting the gloves or deactivating your MODsuit also
snaps MODtethers you've created using it.
Closes#88869Closes#88866Closes#89170
## Changelog
🆑
qol: Snapping tethers now also removes their beacons
qol: You can now cut tethers that you're attached to while in motion
qol: Tethers now snap when you retract your gloves or disable your
MODsuit
fix: Fixed tether stacking issues
/🆑
## About The Pull Request
the module doesn't actually show the visor thanks to the fact that the
module is not actually active at any point, which the visor attempts to
check for
also the color of purple was like WAY too dark it was practically black
on every modsuit
## Why It's Good For The Game
it'd be cool if it actually worked and you could actually see it
## Changelog
🆑
fix: fixes plasma stabilizer module not showing a visor on modsuits
fix: makes the plasma stabilizer module actually visible
fix: makes rave module grey by default as it was meant to be
/🆑
## About The Pull Request
A bunch of places in code were recently updated to use a helper proc for
validating teleportation.
Unfortunately a lot of them also got the return value inverted, and
would only let you teleport to illegal locations. Most notably this
effected the hand teleporter, but also several other items.
Fixes#88966
what is a "dull universal force" supposed to be anyway
## About The Pull Request
see title
## Why It's Good For The Game
if the frequency is ever changed from NT by default for any reason,
pre-loaded scryers wont be able to call normal modsuits because they
dont use the define without this
## Changelog
🆑
code: modlink scryers use the nt frequency define rather than just plain
text doing it themselves
/🆑
## About The Pull Request
Adds a new area flag, LOCAL_TELEPORT.
This flag allows teleports ONLY in the same area that the teleport is
used. This allows for short range hijinks without enabling long range
exploits, and thus it's given to DMs and domains.
Changed almost all area_flags & NO_TELEPORT checks to use
check_teleport() (as now areas may use local_teleport instead, and this
lets them check for multiple things instead)
Thus I re-added Void Phase to the heretic scribe in DM and shuffled some
stuff around
(realizing now i neglected to doublecheck if blade breaking tps you to
station. need to check just in case)
## Why It's Good For The Game
It sucks you can't use teleporting abilities in temporary areas, so this
is a good way to allow this to still happen without opening the way for
gamebreaking exploits.
## Changelog
🆑
code: Adds a new area flag, LOCAL_TELEPORT, given to virtual domains and
deathmatch arenas.
code: Re-added Void Phase to Heretic Scribes in Deathmatch's Ragnarok
map.
/🆑
## About The Pull Request
This PR completely rewrites our embedding system in favor of embedding
datum handlers which acts as containers for all embedding-related data
and logic.
Currently embedding logic relies on an element-component-datum triad,
where elements on the items handle embedding logic, singleton datums
store embedding data and components (which get assigned to ***mobs*** in
whom the item embedded) handle pain and the item being ripped out. How
do we access all the procs? By using comsigs as procs, which is really
bad. This code was written back in 2020 when DCS was hot stuff but in
hindsight this implementation was a mistake, as it heavily restricts
custom embedding behaviors unless you're willing to constantly run
GetComponent (bad, ugly, incarnation of evil)
This PR rewrites all that logic to be handled by lazyloaded
``/datum/embedding``, which is stored similarly to current
``/datum/embed_data``. Upon being requested, it is initialized and
assigned to a parent from whom all the logic is handled, from being
embedded to pain and having the item ripped out. On projectiles this
only handles one proc, after which it copies itself down to the shrapnel
item instead and runs the chain further from there.
Ideally, most embedding-related logic now should be handled purely
datum-side - in most cases items should not be hooking up to themselves
like they did before (unless said logic is for when the item is made
sticky or smth) and instead the code should be handled by the embedding
datum (see sholean grapes implementation in this PR). This should allow
us to do fancy stuff like syringe guns embedding syringes into targets
and injecting them that way, and fix some bugs along the way.
Closes#88115Closes#87946
Also fixed a bug with scars not displaying when examined closely from
#86506 because i was in the area anyways
Renames all uses of caller, as they (currently) shadow the new byond var
and will in future error
Ups our "wan if compiled after" experiement compile version to 516
Adds an alternate 516 unit test
## About The Pull Request
Rave and plasma stabilizer MODules now use per-theme visors so they no
longer look like an ugly blob (because their sprite only works with the
"standard" MODsuit theme)
Armor booster modules use a signal to change the visor when they're
activated
## Why It's Good For The Game
Currently they use the base helmet visor sprite which doesn't look very
good on non-standard MODsuits
## Changelog
🆑
add: Rave and plasma stabilizer MODules now utilize theme-specific
visors
/🆑
## 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
Moth wings prevent you from flying in gravity -> same check is used for
activation -> they're activated upon implanting -> unless you spawn or
get wings in zero-g you're screwed
Closes#88460Closes#88457
## Changelog
🆑
fix: Fixed moths only being able to fly if they spawn in zero gravity
/🆑
## About The Pull Request
generates 2u of space cleaner per second if active
it shoots space cleaner
janitor ert gets it
## Why It's Good For The Game
at long last janitors get some actually useful modsuit module
## Changelog
🆑
add: janitor modsuit space cleaner mister module
/🆑
Closes#88283
Closes https://github.com/tgstation/tgstation/issues/88320
Fixes a harddel caused by the limp status effect not being properly
deleted
Reduces update-body calls in:
- Initialize from 4 to 1
- On z-level change from 2 to 1
- On move with bloody shoes from 1 to 0
Mostly by just passing along the proper argument and removing seemingly
unnecessary update body calls
## About The Pull Request
The recloaking timer of the Wraith module has been bumped from 5 to 20
seconds.
It now decloaks the user on any type of bump, or if you shoot your gun.
The module is now incompatible with armor booster module (Blood red and
Elite)
## Why It's Good For The Game
I originally created this to provide traitors a tool to better setup
ambushes and engage in stealth play.
It was never really meant to be used as Combat camo like Ling darkness
adaptation.
Lastly the combination of full Eva + stealth is a bit bloated; fighting
an invisible man in space is not fun.
## Changelog
🆑
balance: Wraith Module recloaking timer bumped from 5 to 20 seconds.
balance: The Wraith Module's cloak now dissipates on ranged attacks and
any type of bump.
balance: Wraith Module can no longer be installed In suits with the
armor booster module .
/🆑
---------
Co-authored-by: Xander3359 <66163761+Xander3359@users.noreply.github.com>
## About The Pull Request
Not adding a limit on how many you can have attached at once was a
mistake. MODsuits can only attach one tether at a time and they're
*slightly* slower to cut. You still can attach yourself to more than one
anchor manually (or mob via embedding), but this prevents you from being
attached to more than one machine/structure at a time. Tether anchors
now also only support one link at most.
Tethers no longer require you to click on a specific tile and have a
couple of transparent pixels to the side to make them easier to cut in a
hurry.
Closes#88057
## Why It's Good For The Game
## Changelog
🆑
fix: You cannot have more than one MODtether (excluding manual
connections)
qol: Tethers are easier to cut (require less pixelhunting)
/🆑
## About The Pull Request
You can now wear a hat on any modsuit, even w/o the stabilizing module.
However:
- It will always sit slightly askew, at an angle.
- Involuntarily falling to the ground for any reason will cause the hat
to fall to the ground.
- Being thrown, slapped, or slipped will send it flying off.
Added the Atrocinator, Hat Stabilizer, and Tanning modules to the black
market.
Added the loose hat component to bio/bomb/rad hoods and space helmets.
## Why It's Good For The Game
> You can now wear a hat on any modsuit, even w/o the stabilizing
module.
I think the notion of, say, the Head of Security putting his cap on his
modsuit and then being slipped by the clown, who then steals the cap, is
really funny.
https://github.com/user-attachments/assets/3ad8a74d-0cb8-4118-8beb-d2ce9c76b358
The module is fairly rare and sometimes I just want to wear a silly hat
alongside the modsuit without badgering the captain for his hat module.
The downsides are rather plentiful so it's not like the hat module is
made irrelevant - if anything it makes it more notable.
This will add a bunch of enjoyable silliness to rounds, so I think it's
worth it.
> Added the Atrocinator, Hat Stabilizer, and Tanning modules to the
black market.
> Added the loose hat component to bio/bomb/rad hoods and space helmets.
It sucks losing your iconic drip when you need to venture out to space
for whichever reason - this lets you keep it without taking up space in
your bag, while having the throw downside.
They just feel perfect for the vibes of the black market. More
miscellaneous completely useless fancy stuff that has exorbitant prices
please!
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
add: You can now wear a hat on any modsuit, even w/o the stabilizing
module. But it may easily fall off...
add: Added the Atrocinator, Hat Stabilizer, and Tanning modules to the
black market.
add: Added the loose hat component to bio/bomb/rad hoods and space
helmets.
/🆑
~~I'm having a bit of an issue. Somewhere I fugged up and now the worn
overlay on the mod helmet sprite doesn't work properly...~~ Turns out
that code was never used and nonfunctional to begin with so I removed it
entirely yay
## About The Pull Request
Closes#87981
Also respects silent footsteps and lagswitch now
## Changelog
🆑
fix: Fixed atrocinator module footstep spam when you're moving on a tram
/🆑
## 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
This allows you to use a fishing rod during the "manipulate organs" step
of the aforementioned surgery to snatch organs from a target.
Unlike other fish sources, this one has a negative fishing difficulty of
-20, which when summed with the default minigame difficulty should still
result in a negative difficulty. In layman terms, this means the
minigame is skipped here (unless you're wearing some clunky stuff like
insulated or boxing gloves). It also has a wait time of 8 to 13 seconds
versus the more random standard 3 to 25 seconds.
A small side-effect of this is that explosions during the "manipulate
organs" step will basically disembowel you, but it kinda fits anyway.
By the by, because of this, there is a tiny chance bluespace fishing
rods can yield you random organs. Worry not, they're newly generated, so
you won't be snatching it from another player by accident (at least for
now).
## Why It's Good For The Game
It adds more possible weird and rare shenanigans involving surgery.
## Changelog
🆑
Add: You can use a fishing rod to snatch organs during organ
manipulation surgery
/🆑
## About The Pull Request
title
## Why It's Good For The Game
it doesn't fit and doesn't make sense
## Changelog
🆑 grungussuss
sound: the glove pickup sound will no longer play for modsuits
undeploying
/🆑
## About The Pull Request
clickable alerts glow (regex: /atom/movable/screen/alert/.*/Click)
## Why It's Good For The Game
people are much more likely to look at the chat or anywhere else than
the status effect (really, its usually never worth reading 99% of them
so they end up ignored)
## Changelog
🆑
qol: alerts that do stuff when clicked glow gold
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## About The Pull Request
Fixes issues with var typing and proc arguments, discovered using
OpenDream's WIP TypeMaker feature (using improvements I haven't PR'd
upstream yet).
## Why It's Good For The Game
Codebase maintenance.
## About The Pull Request
Significantly buffed the anomalock modules.
Anomalock modules can be used with eachother.
Antigravity module costs 2 complexity.
Teleporter module is thrice as fast at teleporting with a slightly
reduced cooldown, but has a much larger power cost.
Changed how teleporter tracks maximum range to be less painful to the
end user.
Kinesis module's default range has been extended to 8.
Kinesis module can drag around people in critical condition or worse.
## Why It's Good For The Game
These modules have historically been, well, kind of a complete joke.
They seem to have been crippled out of fear of them being overpowering
with the end result of being unusable.
Anomaly items are allowed and meant to be fun, strong, and wild, so I
really don't see why these need to be so weak. The amount of times I'd
rather make a teleporter that takes 3 seconds to get you anywhere
instead of an instant portal gun or a bag of holding is roughly zero.
People hate modsuits, and in part that hate is because of modules which
do very, very little due to severe undertuning. Let's fix that with the
anomaly ones here.
> Anomalock modules can be used with eachother.
Let people get a buncha anomaly modulse together if they want to. An
antigravity user with teleporting and kinesis could be something to
fear, but not so much as to strike it from existence altogether without
even letting people mess around with it first.
> Antigravity module costs 2 complexity.
Antigravity module is glorified wittel -> gravitum, but it takes a core
and 3 complexity. At least let it be somewhat cheap.
> Teleporter module is thrice as fast at teleporting with a slightly
reduced cooldown, but has a much larger power cost.
Teleporter module is a big damn joke ATM, as stated above being
effectively overshadowed in every way by the portal gun. This now gives
it a fun niche instead, of being able to teleport around everywhere at
the cost of a massive power draw.
> Changed how teleporter tracks maximum range to be less painful to the
end user.
view() was working weirdly when I was using it. It was failing to
register tiles somewhat near the end of the screen, so I just ditched it
for a get_dist check that I threw 9 in as a somewhat arbitrary value
for.
> Kinesis module's default range has been extended to 8.
There's this bug on live where when you kinesis someone it flies all the
way to the SW corner of the screen for seemingly no reason. I don't know
why it happens but it drives me mad.
Even without that bug, 5 tiles is extremely frustrating to handle - it's
super, super annoying to find a middleground between 'not slapping you
in the face', 'not losing your grip'. 8 tiles is a lot more forgiving
and makes the module actually fun to use.
> Kinesis module can drag around people in critical condition or worse.
This one might be a bit nuts, but I really want to see this ingame, it's
kind of the best part of the module yet is unobtainable. Maybe some
stuff would need to be tuned for it, like making human throws flimsy.
## Changelog
🆑
balance: Significantly buffed the anomalock modules.
balance: Anomalock modules can be used with eachother.
balance: Antigravity module costs 2 complexity.
balance: Teleporter module is thrice as fast at teleporting with a
slightly reduced cooldown, but has a much larger power cost.
code: Changed how teleporter tracks maximum range to be less painful to
the end user.
refactor: Refactored LoS checks to be a proc on atom, los_check
balance: Kinesis module's default range has been extended to 8.
balance: Kinesis module can drag around people in critical condition or
worse.
/🆑
## About The Pull Request
so there is a problem of:
if 2 modsuit modules were to apply the same trait and 1 were removed,
shit would break
so now all instances of mod_trait applied to the modsuit wearer are refs
instead, with mod_trait used for stuff added to items as that isnt
likely to have the same thing
also qdeleted modsuits delete their parts apparently accidentally
removed at some point. the previous time they did it caused qdel loops
but this time it doesnt
makes boots need to be out for an ai to move someone in a modsuit
improves the ui, non-standard cores now have unique colors for the
charging bar, and you can extend/retract things from ui, also adds a
configurable button to config menu so that the tether doesnt repurpose
the pin function made for circuits
redoes modsuit balloon alerts to use simpler language
makes the weapon recall module make you pick up the weapon if its on
your tile as throws dont work on same tile
## Why It's Good For The Game
futureproofing (also technically presentproofing, if you wear something
like infiltrator and normal back modsuit and both have ai control they
both will give you a trait)
also ai movement doesnt have any checks currently, i think it makes
sense that it would require your boots to be out so that the ai has
something to move
fix stuff change break boom wack
