## About The Pull Request
Revival of https://github.com/tgstation/tgstation/pull/86482, which is
even more doable now that we have rustg iconforge generation.
What this PR does:
- Sets up every single GAGS icon in the game to have their own preview
icon autogenerated during compile. This is configurable to not run
during live. The icons are created in `icons/map_icons/..`
- This also has the side effect of providing accurate GAGS icons for
things like the loadout menu. No more having to create your own
previews.
<details><summary>Mappers rejoice!</summary>
</details>
<details><summary>Uses iconforge so it does not take up much time during
init</summary>
</details>
---
### Copied from https://github.com/tgstation/tgstation/pull/86482 as
this still applies:
Note for Spriters:
After you've assigned the correct values to vars, you must run the game
through init on your local machine and commit the changes to the map
icon dmi files. Unit tests should catch all cases of forgetting to
assign the correct vars, or not running through init.
Note for Server Operators:
In order to not generate these icons on live I've added a new config
entry which should be disabled on live called GENERATE_ASSETS_IN_INIT in
the config.txt
## Why It's Good For The Game
No more error icons in SDMM and loadout.
## Changelog
🆑
refactor: preview icons for greyscale items are now automatically
generated, meaning you can see GAGS as they actually appear ingame while
mapping or viewing the loadout menu.
/🆑
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Melee attack chain now has a list passed along with it,
`attack_modifiers`, which you can stick force modifiers to change the
resulting attack
This is basically a soft implementation of damage packets until a more
definitive pr, but one that only applies to item attack chain, and not
unarmed attacks.
This change was done to facilitate a baton refactor - batons no longer
hack together their own attack chain, and are now integrated straight
into the real attack chain. This refactor itself was done because batons
don't send any attack signals, which has been annoying in the past (for
swing combat).
🆑 Melbert
refactor: Batons have been refactored again. Baton stuns now properly
count as an attack, when before it was a nothing. Report any oddities,
particularly in regards to harmbatonning vs normal batonning.
refactor: The method of adjusting item damage mid-attack has been
refactored - some affected items include the Nullblade and knives.
Report any strange happenings with damage numbers.
refactor: A few objects have been moved to the new interaction chain -
records consoles, mawed crucible, alien weeds and space vines, hedges,
restaurant portals, and some mobs - to name a few.
fix: Spears only deal bonus damage against secure lockers, not all
closet types (including crates)
/🆑
## About The Pull Request
If you examine a soul shard closely, you can learn to craft the MOD soul
shard core. It takes the same basic ingredients as other MOD cores, but
uses a soul shard. It is powered by your own soul, which drains your
sanity to provide charge (if mood is disabled in the config, it's
practically equivalent to an infinite core).
Crafting one ejects any shades in the shard (because that's the simplest
behavior that doesn't require a substantial refactor to crafting or
modsuit code).
Depending on the kind of shard used, certain roles get negatively
impacted by using a modsuit with such a core.
- Cult soul shards wrack non-magical roles (anyone that isn't a cultist,
heretic, heretic minion, or wizard) with horrible agony (a -20 moodlet
that expires 10 seconds after turning the suit off)
- Holy soul shards wrack cultists and heretics with horrible agony,
while wizards are put at unease (-3 mood)
- Wizard soul shards have no negative impact on anyone
- If someone were to VV a soul shard to have the heretic theme (only
used by rusted harvesters), it would be functionally identical to the
cult shard
Soulless mobs (liches, people who lost with the cursed russian revolver,
and people who died from casting Soul Tap too many times) have no soul
for the core to draw power from.
Also gives the wizard modsuit a soul core.
## Why It's Good For The Game
Provides a neat but caveat-rich way to utilize soul shards, especially
for players who have no way to obtain construct shells absent a cult or
wizard to create them.
## 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
Melee attack chain now has a list passed along with it,
`attack_modifiers`, which you can stick force modifiers to change the
resulting attack
This is basically a soft implementation of damage packets until a more
definitive pr, but one that only applies to item attack chain, and not
unarmed attacks.
This change was done to facilitate a baton refactor - batons no longer
hack together their own attack chain, and are now integrated straight
into the real attack chain. This refactor itself was done because batons
don't send any attack signals, which has been annoying in the past (for
swing combat).
## Changelog
🆑 Melbert
refactor: Batons have been refactored again. Baton stuns now properly
count as an attack, when before it was a nothing. Report any oddities,
particularly in regards to harmbatonning vs normal batonning.
refactor: The method of adjusting item damage mid-attack has been
refactored - some affected items include the Nullblade and knives.
Report any strange happenings with damage numbers.
refactor: A few objects have been moved to the new interaction chain -
records consoles, mawed crucible, alien weeds and space vines, hedges,
restaurant portals, and some mobs - to name a few.
fix: Spears only deal bonus damage against secure lockers, not all
closet types (including crates)
/🆑
## About The Pull Request
If you examine a soul shard closely, you can learn to craft the MOD soul
shard core. It takes the same basic ingredients as other MOD cores, but
uses a soul shard. It is powered by your own soul, which drains your
sanity to provide charge (if mood is disabled in the config, it's
practically equivalent to an infinite core).
Crafting one ejects any shades in the shard (because that's the simplest
behavior that doesn't require a substantial refactor to crafting or
modsuit code).
Depending on the kind of shard used, certain roles get negatively
impacted by using a modsuit with such a core.
- Cult soul shards wrack non-magical roles (anyone that isn't a cultist,
heretic, heretic minion, or wizard) with horrible agony (a -20 moodlet
that expires 10 seconds after turning the suit off)
- Holy soul shards wrack cultists and heretics with horrible agony,
while wizards are put at unease (-3 mood)
- Wizard soul shards have no negative impact on anyone
- If someone were to VV a soul shard to have the heretic theme (only
used by rusted harvesters), it would be functionally identical to the
cult shard
Soulless mobs (liches, people who lost with the cursed russian revolver,
and people who died from casting Soul Tap too many times) have no soul
for the core to draw power from.
Also gives the wizard modsuit a soul core.
## Why It's Good For The Game
Provides a neat but caveat-rich way to utilize soul shards, especially
for players who have no way to obtain construct shells absent a cult or
wizard to create them.
## 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.
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
So yesterday I've spotted that we had wrong SLOTS_AMT value set, and
went a bit down a rabbit hole and found how abhorrent our
ITEM_SLOT_BACKPACK and ITEM_SLOT_BELTPACK usage is. They're not real
inventory slots, but just "hints" at items being located in backpacks or
belts, or instructions to put an item into a belt/backpack. This PR
rewrites all usages of them as "hints", and adds an equip_to_storage
proc used to equip an item into a storage positioned in a certain slot,
so ``equip_to_slot_if_possible(item, ITEM_SLOT_BACKPACK)`` is now
``equip_to_storage(item, ITEM_SLOT_BACK)``
## Why It's Good For The Game
Its really stupid and we shouldn't have those as slot flags,
ITEM_SLOT_HANDS at least makes sense but those two are just absurd.
Should make equipping things into non-backpack storage a bit easier too,
in case we end up going through with the idea of suit/uniform pockets
being a major part of player inventory.
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and its effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
refactor: Refactored how backpack and belt contents are handled in mob
inventory code, report any issues with lingering item effects or
inability to equip things into them!
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
So yesterday I've spotted that we had wrong SLOTS_AMT value set, and
went a bit down a rabbit hole and found how abhorrent our
ITEM_SLOT_BACKPACK and ITEM_SLOT_BELTPACK usage is. They're not real
inventory slots, but just "hints" at items being located in backpacks or
belts, or instructions to put an item into a belt/backpack. This PR
rewrites all usages of them as "hints", and adds an equip_to_storage
proc used to equip an item into a storage positioned in a certain slot,
so ``equip_to_slot_if_possible(item, ITEM_SLOT_BACKPACK)`` is now
``equip_to_storage(item, ITEM_SLOT_BACK)``
## Why It's Good For The Game
Its really stupid and we shouldn't have those as slot flags,
ITEM_SLOT_HANDS at least makes sense but those two are just absurd.
Should make equipping things into non-backpack storage a bit easier too,
in case we end up going through with the idea of suit/uniform pockets
being a major part of player inventory.
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and its effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
refactor: Refactored how backpack and belt contents are handled in mob
inventory code, report any issues with lingering item effects or
inability to equip things into them!
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
## About The Pull Request
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>
A recent upstream changed how modsuits overslotting on clothing is
handled.
This is a temporary revert back to old behavior, until it's decided how
we're going to handle this.
People can now pet held mothroaches and pugs if they want to, or use
items on them, hopefully without causing many issues. After all, it only
took about a couple dozen lines of code to make...
...Oh, did the 527 files changed or the 850~ lines added/removed perhaps
catch your eye? Made you wonder if I accidentally pushed the wrong
branch? or skewed something up big time? Well, nuh uh. I just happen to
be fed up with the melee attack chain still using stringized params
instead of an array/list. It was frankly revolting to see how I'd have
had to otherwise call `list2params` for what I'm trying to accomplish
here, and make this PR another tessera to the immense stupidity of our
attack chain procs calling `params2list` over and over and over instead
of just using that one call instance from `ClickOn` as an argument. It's
2025, honey, wake up!
I also tried to replace some of those single letter vars/args but there
are just way too many of them.
Improving old code. And I want to be able to pet mobroaches while
holding them too.
🆑
qol: You can now interact with held mobs in more ways beside wearing
them.
/🆑
## About The Pull Request
Fixes https://github.com/NovaSector/NovaSector/issues/5311
Fix some unreachable code and some broken invariants
## Why It's Good For The Game
bug bad modsuit good
## Changelog
🆑
fix: Passive modsuit modules (radiation protection, welding protection,
etc) should work reliably again.
/🆑
## About The Pull Request
This makes it so if you try to use a MODlink scryer without a power
cell, or with an empty cell, it'll show a balloon alert to the user
saying "no cell installed!" or "no charge!", rather than silently
failing.
## Why It's Good For The Game
when I ported modlinks downstream, a few people got confused bc they
didn't realize they needed cells after being printed.
this makes it more clear what the issue is.
## Changelog
🆑
qol: MODlink scryers now alert the user if they try to call without a
charged power cell.
/🆑
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
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
People can now pet held mothroaches and pugs if they want to, or use
items on them, hopefully without causing many issues. After all, it only
took about a couple dozen lines of code to make...
...Oh, did the 527 files changed or the 850~ lines added/removed perhaps
catch your eye? Made you wonder if I accidentally pushed the wrong
branch? or skewed something up big time? Well, nuh uh. I just happen to
be fed up with the melee attack chain still using stringized params
instead of an array/list. It was frankly revolting to see how I'd have
had to otherwise call `list2params` for what I'm trying to accomplish
here, and make this PR another tessera to the immense stupidity of our
attack chain procs calling `params2list` over and over and over instead
of just using that one call instance from `ClickOn` as an argument. It's
2025, honey, wake up!
I also tried to replace some of those single letter vars/args but there
are just way too many of them.
## Why It's Good For The Game
Improving old code. And I want to be able to pet mobroaches while
holding them too.
## Changelog
🆑
qol: You can now interact with held mobs in more ways beside wearing
them.
/🆑
## About The Pull Request
Fixes https://github.com/NovaSector/NovaSector/issues/5311
Fix some unreachable code and some broken invariants
## Why It's Good For The Game
bug bad modsuit good
## Changelog
🆑
fix: Passive modsuit modules (radiation protection, welding protection,
etc) should work reliably again.
/🆑
## About The Pull Request
This makes it so if you try to use a MODlink scryer without a power
cell, or with an empty cell, it'll show a balloon alert to the user
saying "no cell installed!" or "no charge!", rather than silently
failing.
## Why It's Good For The Game
when I ported modlinks downstream, a few people got confused bc they
didn't realize they needed cells after being printed.
this makes it more clear what the issue is.
## Changelog
🆑
qol: MODlink scryers now alert the user if they try to call without a
charged power cell.
/🆑
## 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 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
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
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](https://github.com/SpaceManiac/SpacemanDMM/commit/4b77cd487d0a7b6a069df20356b701af5b20489d)
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.
/🆑
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.
It just works
🆑 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
#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
/🆑
