Requires #5420 to be merged.
## About The Pull Request
See changelog
## Why It's Good For The Game
Bug fixes are good. Especially fixing bugs that brick you.
## Proof Of Testing
## Changelog
🆑
fix: Click dragging a protean modsuit onto yourself no longer unequips
it, bricking you.
del: Removed the Control Click Stripping functionality from Protean
modsuits. It's now only click dragging.
/🆑
## About The Pull Request
Fixes#93359
Caused by #93165
Inventory screen elements were no longer considered reachable, which
broke mousedrop handing on objects that check "is dragging into
inventory slot"
I don't know the best way to fix this yet but I figured the next best
thing would be to make all of these use the `drag_pickup` element, which
skips this reach-ability check
Thus I refactored it slightly to accommodate for items which should
contextually not be drag-pick-up-abble and bam, works like a charm
## Changelog
🆑 Melbert
fix: Dragging defibs and modsuits off your back works again
/🆑
---------
Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com>
Co-authored-by: Xander3359 <66163761+Xander3359@users.noreply.github.com>
## About The Pull Request
Most of these changes are centered around removing `mod.wearer`
references in module function bubble alerts. However, I cleaned up a few
other things that I thought were easy fixes. ~~This PR should be
testmerged~~ nah send it. I think I did a pretty good job testing, but
there might be a bug or two I missed. (debug modsuit should allow
conflicting modules and have unlimited complexity btw)
### Track who clicks the activate button
* Adds `mob/activator` to `on_select()`, `activate()`, `deactivate()`,
`used()`, `on_activation()`, `on_deactivation()` and `on_use()`
* `mod_ui` now passes `ui.user`, which is who actually clicked the
button in the UI.1
* module action proc now passes the person clicking.
* **Alert bubbles:** Modifies many module code bubbles to pass the
activation bubble text to `mob/activator` instead of `mob.wearer` so
that pAIs get feedback on why clicking the button isn't working.
### Cargo clamp
* **Clamp code cleanup:** The cargo clamp now has a variable for the max
creature weight it can support, and the logic is changed around a bit to
support this.
* The cargo clamp uses an `accepted_items` typecache.
### Code cleanup
* **Button malfunction chance** is controlled by a
`MOD_MALFUNCTION_PROB` define.
* **Pathfinder runtime:** `mod_control`'s `GetAccess()` now checks if
there is an access before returning it. (This previously caused runtimes
when using the pathfinder module if you didn't swipe your ID)
* **Pathfinder code tweaks:** Reworks the code for the pathfinder module
a bit. Activation logic is now stored in the module instead of the
implant. The suit is prevented from being recalled by pAIs, which is
controlled by a variable.
* Adds `MODULE_ALLOW_UNWORN`, which lets you activate modules in suits
that aren't currently being worn. Module activation code now smoothly
supports modules being activated while not worn.
* Chameleon module now works when unworn.
This will probably be a Part 1, with a Part 2 to follow. Actions are
kinda funky and could probably be cleaned up a little better. Plus, I
want to make selectable modules theoretically usable by the AI, even if
I leave it disabled.
## Why It's Good For The Game
This PR doesn't contain any balance changes, and I manually disabled any
new serious functionality that pAIs might gain. (Such as being able to
activate the pathfinder implant) They *can* use the chameleon module
with no wearer- but I'm going to consider this a bug that they couldn't
before.
Paves the way for more pAI modsuit nonsense I'm doing downsteam.
## Changelog
🆑 Stonetear
refactor: MODsuit module code now knows who clicked the activation
button.
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
Fixes#85028
Obscured flags and covered flags are tracked on carbons, updated as
items are equipped and unequipped. It's that shrimple.
Closes#92760
Just removes the species exception checks for not making sense
Also refactors handcuffs / legcuffs removal. In all of these situations
they were hardcoded when they could easily just use an inventory proc to
work.
## Why It's Good For The Game
Stops a million excessive calls to `check_obscured_slots`
Makes obscured behavior more consistent
Makes obscured behavior easier to use
Cleans up human rendering (There was some cursed stuff before with
render item -> updated obscured -> update body -> cause side effects)
## Changelog
🆑 Melbert
del: Golems which somehow manage to grow wings and somehow manage to
equip something that covers their jumpsuit can no longer fly.
(Seriously, this will not affect anyone)
refactor: Refactored clothing obscurity entirely. Items should be a
loooot more consistent and what covers what, and should update a lot
snappier. As always, report any oddities, like mysteriously disappearing
articles of clothing, hair, or species parts
refactored: Refactored handcuffs and legcuffs a bit, report any odd
situations with cuffs like getting stuck restrained
/🆑
## About The Pull Request
- Proteans can now copy MOD plating directly without needing a full
suit.
- Fixes the storage modules vanishing when assimilating modsuits.
Modules inside the original suit will now be placed into a cache which
will return when the suit is removed.
## Why It's Good For The Game
Fixes good, plus some much needed tune ups based on feedback.
## Proof Of Testing
It works
## Changelog
🆑
add: Proteans can now directly copy modsuit plating to transform their
suit without needing an entire modsuit.
fix: Storage modules on proteans will no longer delete when assimilating
suits. It prioritizes the incoming storage and "pushes aside" the old
storage until the suit is removed.
/🆑
## About The Pull Request
``update_clothing`` by default doesn't update anything. Also fixed a
missing return in ``allow_attack_hand_drop`` that always failed the
proc.
## About The Pull Request
``update_clothing`` by default doesn't update anything. Also fixed a
missing return in ``allow_attack_hand_drop`` that always failed the
proc.
## About The Pull Request
Adds the funny nanite blob dudes from Vigro code into the game. It's
more of a port of the idea since they're coded from the ground up. They
will be more of a utility focused species then a combat focused species.
**They are fragile.**
- Eats metal. You need metal to live and you need metal to heal.
- Healed by materials. You feed Proteans metal to heal them.
- Difficult to kill, but extremely fragile. They are considered a
deathless species but they are stuck in their suit if they die. **You
have to order a new refactory from cargo to revive them**
**Order Refactory > Screwdriver suit > Insert refactory > Wait 5
minutes.**
- Easily dismembered. They have 30 seconds to recover their limbs and
pop them on or they will melt into nothingness. Can do a lengthy heal
which replaces missing limbs and easy to replace organs.
- Without a refactory, you will wither away.
- Without an orchastrator, you will have a lot of issues moving.
- You can lock your suit on someone. (OOC escape will work)
- You can assimilate modsuits.
- [x] OOC escape
- [x] Suit Transformation fixes
- [x] Modsuit Assimilation
- [x] Ensure organs are working
- [x] Species info and lore
- [x] Antag Proteans
- [x] Custom damage. Disable various surgeries.
- [x] Testing, polish, feedback.
- [x] Runtime and CI fixing.
- [ ] Live testing and balance.
## Why It's Good For The Game
This was the second to top vote on species people wanted to see added
and this is more custom mechanics then what is just a human reskin.
## Proof Of Testing
## Changelog
🆑 StrangeWeirdKitten, Majkl-J
add: New species: Proteans
/🆑
---------
Co-authored-by: Waterpig <49160555+Majkl-J@users.noreply.github.com>
Co-authored-by: Bubberbot <151680451+Bubberbot@users.noreply.github.com>
Co-authored-by: Arturlang <24881678+Arturlang@users.noreply.github.com>
Co-authored-by: aKromatopzia <94389683+aKromatopzia@users.noreply.github.com>
Co-authored-by: Jinshee <96621959+Jinshee@users.noreply.github.com>
Co-authored-by: Jinshee <manastra2536@gmail.com>
Co-authored-by: JustMeTheIInd <145101584+JustMeTheIInd@users.noreply.github.com>
Co-authored-by: nevimer <77420409+nevimer@users.noreply.github.com>
Co-authored-by: Odairu <39929315+Odairu@users.noreply.github.com>
Co-authored-by: LT3 <83487515+lessthnthree@users.noreply.github.com>
Co-authored-by: Roxy <75404941+TealSeer@users.noreply.github.com>
MODsuit modules now render on the part they're attached to, that being
first part if required_slots is set, otherwise defaulting to the control
module. Instead of using icon ops and a cache, module masking (used by
armor boosters and insignias) will instead render the module on all
parts, each overlay alpha filtered using the worn piece as the mask. To
do this we also migrate modules to separate_worn_overlays, which fixes
the issue where they'd always get painted the same color as the back
piece, ignoring use_mod_colors's value (which is FALSE by default). So
now modules that inherit MOD's color like armor booster will be painted
accordingly to their piece.
This also means that modules actually layer properly, and don't go ontop
of items that they should be under.
Additionally, whenever gloves or boots overslot an item, the overslotted
item will still render underneath them if they're unsealed. Because it
looks weird when your gloves disappear when you extend your MODsuit
ones.
Look at that hip look, she'd have bare hands and ankles without this PR.
Closes#90370
Fixes a bunch of visual jank that looks weird, and overslotting
displaying overslotted item is just behavior you'd expect normally.
🆑
add: When a MODsuit piece overslots an item, it will now render beneath
that piece as long as its unsealed.
refactor: Refactored how MODsuit modules are rendered, report any bugs
on GitHub!
/🆑
## About The Pull Request
MODsuit modules now render on the part they're attached to, that being
first part if required_slots is set, otherwise defaulting to the control
module. Instead of using icon ops and a cache, module masking (used by
armor boosters and insignias) will instead render the module on all
parts, each overlay alpha filtered using the worn piece as the mask. To
do this we also migrate modules to separate_worn_overlays, which fixes
the issue where they'd always get painted the same color as the back
piece, ignoring use_mod_colors's value (which is FALSE by default). So
now modules that inherit MOD's color like armor booster will be painted
accordingly to their piece.
This also means that modules actually layer properly, and don't go ontop
of items that they should be under.
Additionally, whenever gloves or boots overslot an item, the overslotted
item will still render underneath them if they're unsealed. Because it
looks weird when your gloves disappear when you extend your MODsuit
ones.
Look at that hip look, she'd have bare hands and ankles without this PR.
Closes#90370
## Why It's Good For The Game
Fixes a bunch of visual jank that looks weird, and overslotting
displaying overslotted item is just behavior you'd expect normally.
## Changelog
🆑
add: When a MODsuit piece overslots an item, it will now render beneath
that piece as long as its unsealed.
refactor: Refactored how MODsuit modules are rendered, report any bugs
on GitHub!
/🆑
## 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
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 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
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
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
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
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.
/🆑
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
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
## About The Pull Request
generally cleans up the code a bit. fixes the issue where if you had
clothing on yourself already and you tried extending when active it
still went through the sealing process even though it didnt extend the
part, causing weird desyncs. fixes the issues with part enabled modules
that would not activate, makes stealth and radproof modules require the
whole suit to be out cause thinking about it they wouldnt really work
without that i think
reverts quick activation to try put parts on you instead of removing
them as priority, i think that plays nicer with separate part activation
fixes#87413
## About The Pull Request
#86825 allowed MODsuits to only have a few of their parts deployed but
didn't change MODule overlay code, resulting in modules like welding
visor showing up even if you only have your gloves active.
## Why It's Good For The Game
Glitchy visuals begone.
## Changelog
🆑
fix: MODules don't create visual overlays when their required part isn't
deployed
/🆑
---------
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
## About The Pull Request
you no longer need all parts deployed to activate a modsuit
in order to use a module it needs its required part deployed, eg
magnetic attachment = boots needed
passive effects from a module dont work unless the relevant parts are
deployed
video todo
## Why It's Good For The Game
fikou wants this and uhh i guess its better that the legless and the
armless are capable of using modsuits
however wearing a modsuit onearmed or onelegged properly still needs a
seperate PR
## Changelog
🆑
balance: you no longer need all parts deployed to activate a modsuit,
you can use them limbless
/🆑
---------
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
3591 individual conflicts
Update build.js
Update install_node.sh
Update byond.js
oh my fucking god
hat
slow
huh
holy shit
we all fall down
2 more I missed
2900 individual conflicts
2700 Individual conflicts
replaces yarn file with tg version, bumping us down to 2200-ish
Down to 2000 individual conflicts
140 down
mmm
aaaaaaaaaaaaaaaaaaa
not yt
575
soon
900 individual conflicts
600 individual conflicts, 121 file conflicts
im not okay
160 across 19 files
29 in 4 files
0 conflicts, compiletime fix time
some minor incap stuff
missed ticks
weird dupe definition stuff
missed ticks 2
incap fixes
undefs and pie fix
Radio update and some extra minor stuff
returns a single override
no more dupe definitions, 175 compiletime errors
Unticked file fix
sound and emote stuff
honk and more radio stuff
## About The Pull Request
<details>
- renamed ai folder to announcer
-- announcer --
- moved vox_fem to announcer
- moved approachingTG to announcer
- separated the ambience folder into ambience and instrumental
-- ambience --
- created holy folder moved all related sounds there
- created engineering folder and moved all related sounds there
- created security folder and moved ambidet there
- created general folder and moved ambigen there
- created icemoon folder and moved all icebox-related ambience there
- created medical folder and moved all medbay-related ambi there
- created ruin folder and moves all ruins ambi there
- created beach folder and moved seag and shore there
- created lavaland folder and moved related ambi there
- created aurora_caelus folder and placed its ambi there
- created misc folder and moved the rest of the files that don't have a
specific category into it
-- instrumental --
- moved traitor folder here
- created lobby_music folder and placed our songs there (title0 not used
anywhere? - server-side modification?)
-- items --
- moved secdeath to hailer
- moved surgery to handling
-- effects --
- moved chemistry into effects
- moved hallucinations into effects
- moved health into effects
- moved magic into effects
-- vehicles --
- moved mecha into vehicles
created mobs folder
-- mobs --
- moved creatures folder into mobs
- moved voice into mobs
renamed creatures to non-humanoids
renamed voice to humanoids
-- non-humanoids--
created cyborg folder
created hiss folder
moved harmalarm.ogg to cyborg
-- humanoids --
-- misc --
moved ghostwhisper to misc
moved insane_low_laugh to misc
I give up trying to document this.
</details>
- [X] ambience
- [x] announcer
- [x] effects
- [X] instrumental
- [x] items
- [x] machines
- [x] misc
- [X] mobs
- [X] runtime
- [X] vehicles
- [ ] attributions
## Why It's Good For The Game
This folder is so disorganized that it's vomit inducing, will make it
easier to find and add new sounds, providng a minor structure to the
sound folder.
## Changelog
🆑 grungussuss
refactor: the sound folder in the source code has been reorganized,
please report any oddities with sounds playing or not playing
server: lobby music has been repathed to sound/music/lobby_music
/🆑
Because the wings were in fact made of wax
## About The Pull Request
Storage goes to the very bottom of the interaction chain, hardcoded in
on `/atom`.
This is not preferred, obviously, but it ends up being a lot less
snowflaking overall.
Tables also go at the very bottom by extending `base_item_interaction`.
Fixes#83742Fixes#84434Fixes#83982Fixes#85516Fixes#84990Fixes#84890Closes#85036Closes#84025 (RMB places it on the table.)
Closes#86616
Other changes:
Refactored pod storage to be less jank. Patches some exploits around it.
## Why It's Good For The Game
Should make a lot more interactions a lot more reliable... hopefully
## Changelog
🆑 Melbert
refactor: Storage and Tables are now a lower priority action, meaning
some uses of items on storage should work... better, now. Here's hoping
at least, report any oddities.
refactor: Note: For an overwhelming majority of items, **combat mode**
will attempt to attack/insert into the target, while **non-combat-mode**
will attempt to use on a target. This means screwdrivering or emagging a
MODsuit must be done on non-combat-mode, as combat mode will simply put
the screwdriver or emag into its storage. Same applies to tables, though
when in doubt, RMB may help (for things which are also weapons, like
mops).
refactor: Refactored escape pod storage, now they actually properly show
as unlocked on red alert and above.
/🆑
## About The Pull Request
Civilian MODsuit got its visor back but lost its lower helmet piece,
exposing the mouth and chin. It also decided to hit up the gym and lost
weight, as after it became a separate theme it no longer has a slowdown.
Additionally, made sure that mouthhole module cannot be installed on
MODsuits that don't have a helmet or a mask that cover the face.
## Why It's Good For The Game
It looks extremely odd and bulky despite not providing a slowdown. Also
the visor was cool.
## Changelog
🆑
fix: Mouthhole module can no longer be installed on MODsuits that don't
cover the mouth
image: Civilian MODsuit got a resprite
/🆑
## About The Pull Request
this is a revival of #82635 . i got permission from potato to reopen
this, he did almost all the work. i only just solved the conflicts and
fixed all the bugs that were preventing the original from being merged
(but it should be TMed first)
## Why It's Good For The Game
slightly improves the performance of basic mob AI
## Changelog
🆑
LemonInTheDark
refactor: able_to_run and incapacitated have been refactored to be event
based
/🆑
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: ZephyrTFA <matthew@tfaluc.com>
* Callouts and MODsuit quick module pickers now track user (#85418)
## About The Pull Request
Callout and MODsuit quick picker (Ctrl + MMB) radials are now
user-bound, meaning that they won't change their screen position if you
move.
## Why It's Good For The Game
Those aren't radials bound to specific objects and rather appear at your
cursor purely for convenience. In case of callouts this is especially
important as you're most likely running while casting them which will
make your mouse move over and trigger a random option as you don't have
to click to use them.
## Changelog
🆑
qol: Callouts and MODsuit quick module pickers now track user
/🆑
* Callouts and MODsuit quick module pickers now track user
---------
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
## About The Pull Request
Callout and MODsuit quick picker (Ctrl + MMB) radials are now
user-bound, meaning that they won't change their screen position if you
move.
## Why It's Good For The Game
Those aren't radials bound to specific objects and rather appear at your
cursor purely for convenience. In case of callouts this is especially
important as you're most likely running while casting them which will
make your mouse move over and trigger a random option as you don't have
to click to use them.
## Changelog
🆑
qol: Callouts and MODsuit quick module pickers now track user
/🆑
* Using ctrl + your quick MOD button now opens module selector on your mouse position (#84879)
## About The Pull Request
Title. Ctrl + middle by default, can be ctrl + alt + LMB if changed in
prefs. Both are unused and default to ctrl/alt click behavior
respectively.
## Why It's Good For The Game
A quick way to change modules. You *can* bind your module wheel to a
hotkey but that still opens it on your sprite, making it harder to
quickly swap modules in combat/danger.
## Changelog
🆑
qol: Using ctrl + your quick MOD button now opens module selector on
your mouse position
/🆑
* Using ctrl + your quick MOD button now opens module selector on your mouse position
---------
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
## About The Pull Request
Title. Ctrl + middle by default, can be ctrl + alt + LMB if changed in
prefs. Both are unused and default to ctrl/alt click behavior
respectively.
## Why It's Good For The Game
A quick way to change modules. You *can* bind your module wheel to a
hotkey but that still opens it on your sprite, making it harder to
quickly swap modules in combat/danger.
## Changelog
🆑
qol: Using ctrl + your quick MOD button now opens module selector on
your mouse position
/🆑
* Fixes mod paint kit (#84835)
## About The Pull Request
After all the attack chain refactors, the modsuit paint kit was bugged.
If you tried to use it on a modsuit that had storage installed, then the
paint kit would simply be inserted into the modsuit instead of allowing
you to change the skin/color.
Fixes#84620Fixes#84490
## Changelog
🆑
fix: The modsuit paint kit is no longer broken.
/🆑
* Fixes mod paint kit
---------
Co-authored-by: GPeckman <21979502+GPeckman@users.noreply.github.com>
Alexis