* Fixes mind traits (Curator, Miner, Clown) (#75593)
## About The Pull Request
Tower of Babel (Curator), Naive (Clown), and Storm detector (Shaft
Miner), are all traits that are given to your mind upon taking these
jobs.
However, we have been checking the body for these traits, not the mind.
This meant that Shaft miners werent alerted of ice storms, Clowns didnt
have their unique examine text, and Curators were affected by Tower of
Babel.
This fixes all those issues.
Naive and Tower of Babel realistically should only be on the mind, so I
changed all instances to check the mind. Storm detection is something
you can get through analyzers, so I left it as a check for both your
body and mind traits.
Clown's Naive:
Tower of Babel:
## Why It's Good For The Game
Fixes several bugs for 3 jobs all at once. I don't see any issue reports
on any of these, but they existed.
## Changelog
🆑
fix: Shaft Miners are now alerted of Icemoon storms, Clowns are naive,
and Curators are immune to the Tower of Babel again.
/🆑
* Fixes mind traits (Curator, Miner, Clown)
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* initial - adds head .dmi files
* mush cap was moved to costume forever ago but not the links
* Move all the helmet links to the new .dmis
* add muzzled variant to hecksuit
* this icon was an actual mess im just gonna toss it
* Remove dupe black fedora, swap brown to use detective sprite with no candycorn
* remove practically unused fallout enclave hats
arent these guys fascists or nazis or something?
* remove beret, replace it with a gags equivalent
this one is even armored, so
* deletes an ass load of old icons + a missed obj icon
* you werent supposed to see that.
* it'd probably help if these linked to the right file
* remove empty sprite state
* remove hidesnout from riot helmet, add snouted var to DS2 SWAT
* Fix CI
* a single fucking "
* these single letters are ruining me
---------
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* Makes industrial gold and regenerative gold spawn random coins. Also adds chococoin to coin spawner. (#75199)
<!-- 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 they just had list from 6 coins and not random picking of coins, so
now its random.
It will also spawn chococoin because it's a coin too.
But won't spawn `coin/gold/debug` because it's debug and eldritch coin
because comxy asked about it.
Added chococoin to `/obj/effect/spawner/random/entertainment/coin` and
holdables list of wallet.
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
Random is funny.
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and 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: Indusrial Gold and Regenerative Gold extracts now spawn random
coins and not just list of 6 coins. But no mythril as it has miserable
chance to have summoning effect which have even more miserable chance to
spawn something dangerous and not just mice.
add: Chococoin now has a chance to spawn wherever the coins are used to
spawn (wallets, greed ruins, deltastation bar)
/🆑
<!-- 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. -->
---------
Co-authored-by: Fikou <23585223+Fikou@ users.noreply.github.com>
* Makes industrial gold and regenerative gold spawn random coins. Also adds chococoin to coin spawner.
---------
Co-authored-by: Helg2 <93882977+Helg2@users.noreply.github.com>
Co-authored-by: Fikou <23585223+Fikou@ users.noreply.github.com>
* Flora (like trees, rocks and etc.) now drops materials when destroyed. (#75070)
<!-- 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
I find it strange that you don't get anything if you just break tree or
rock with brute force. So you will now get something but with 0.6
multiplier.
I chose 0.6 multiplier so using tools are still preferable, but you
still get amount of recourses you can do something with.
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
You can gather some materials if you have no tools besides the toolbox.
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and 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. -->
🆑
qol: Trees, rocks, grass and etc. now drop materials when destroyed.
/🆑
<!-- 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. -->
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@ users.noreply.github.com>
* Flora (like trees, rocks and etc.) now drops materials when destroyed.
---------
Co-authored-by: Helg2 <93882977+Helg2@users.noreply.github.com>
Co-authored-by: John Willard <53777086+JohnFulpWillard@ users.noreply.github.com>
* Hierophant club appearance updates properly; works if summoned into hand. (#75116)
## About The Pull Request
Fixed a pair of bugs with the hierophant club.
First, the appearance of the club would not update properly to display
whether or not the beacon is attached. The icon state was only ever
updated when the blink action was used, rather than when the beacon was
actually manipulated. It now updates at sensible times.
Second, the blink action was granted when the hierophant club was
_picked up,_ rather than equipped into hand. This meant that if the club
was placed in your hand by any means other than picking up (most
relevantly, by casting Instant Summons, something miners can reasonably
get their hands on), the blink action would not work unless you drop it
and pick it up again. It now uses the `equipped()` proc to do this
correctly.
## Why It's Good For The Game
Visual feedback is useful to know whether or not you have a beacon
deployed - since the UI button doesn't change at all to tell you this
information.
The summoning bug is minor, but could cause problems for miners who have
acquired both the club and Instant Summons - the bug could ruin a
perfectly good getaway plan.
## Changelog
🆑
fix: The hierophant club's sprite updates when it should
fix: The hierophant club grants the blink action when summoned into hand
/🆑
* Hierophant club appearance updates properly; works if summoned into hand.
---------
Co-authored-by: lizardqueenlexi <105025397+lizardqueenlexi@users.noreply.github.com>
* Ore silo will put machines off its level on hold, instead of disconnecting (#74990)
## About The Pull Request
There's a problem where people would try to rebuild a whiteship and use
an Ore Silo for it. However, it would automatically unlink everything
when moving, because it's checking for z level as soon as it changes z
level itself, before the Ore silo has 'moved' as well.
~~To fix this, I'm now only disconnecting ore silos when a shuttle
moves. This mostly does the same as before, but technically you can sync
an unwrenchable connected machine and bring it to space with you
(without using a shuttle) to stay connected, but I don't see this as a
problem, and my original point of the PR was to prevent Lavaland ORMs.~~
I decided against this, instead I've made it so machines that aren't on
a valid level (either both on the same z level or both on the station
level) will be considered 'on-hold', much like if the QM has set it to
hold through the silo directly. This means that machines no longer
disconnect from the Ore silo on moving, they just can't access the
materials in it. This affects gameplay in 2 ways:
1. You no longer need to resync when you bring the machine back
2. It won't unsync itself every time you move station z-level with its
silo (such as on a whiteship).
I also made disconnecting from an ore silo actually remove them from the
ore silo's list of connected machines.
## Why It's Good For The Game
Closes https://github.com/tgstation/tgstation/issues/69863
## Changelog
🆑
balance: Machines (such as ORM and Techfabs) will no longer unsync from
Ore silos when it moves Z-level, instead it will prevent materials from
being used, as if it was on hold.
/🆑
* Ore silo will put machines off its level on hold, instead of disconnecting
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* You can now move dirt (#75028)
## About The Pull Request
Changed the recipe for dirt piles from 3 sandstone bricks to 3 sand.
And made the dirt pile drop these 3 sand on deconstruction instead of
just disappearing.
Also fixed hydrotrays resetting their water and nutriments on
construction.
## Why It's Good For The Game
You could accidentally click on the wrong mouse button and loose your
dirt pile instead of uprooting a plant.
And it didn't make sense why you would need to turn sand into bricks
before making a pile out of it.
## Changelog
🆑
qol: Dirt pile is crafted from sand instead of sandstone and drops it on
deconstruction
fix: You can't have free water and nutriments by rebuilding hydrotray
/🆑
* Move dirt
---------
Co-authored-by: Andrew <mt.forspam@gmail.com>
* Miner Style Points 2: Style on Everyone (#74690)
## About The Pull Request
A re-open of https://github.com/tgstation/tgstation/pull/66326 with
Fikou's permission
Adds the style meter, it can be bought from the mining vendor for 1500
points, it is an attachment to your glasses.
The style meter creates a display on your hud, with your recent actions,
like attacking enemies, killing them, mining ore etc. Actions like
spinning or flipping increase your score multiplier, making you get more
points.
Your style meter affects how much ore you get from mining rocks. By
default with the meter, you get 20% less ore, but at the highest, you
can get 1.2x the ore from mining. In addition, on B-tier or above, you
can "hotswap" items, by attacking an item in your backpack with one in
your hand (should it fit and all that). Also features a leaderboard for
highest style point count!
New streamable: https://streamable.com/eewi6l
The following are sources of points:
- Killing things
- Killing big things
- Killing small things
- Punching things
- Melee'ing things
- Mining rocks and ores
- Having matrix traps detonate
- Hit, defuse, and detonate gibtonite
- Detonate crusher marks
- Scan geysers
- Parry projectiles (others or your own)
Oh, right. While wearing the style meter, you're able to parry any
lavaland-based projectile by clicking on it or the tile it is on, which
reflects it back in a 7 degree arc, making it 20% faster and 15% more
damaging. Usually not very easy.
Maybe-plan in the future for some syndicate variant of this (with bullet
parrying and appropriate style sources, etc.), but not for this PR
Thanks to Arcane, multitooling the style meter will make it play some
sounds on rank-up.
https://streamable.com/nheaky
Parrying in action
## Why It's Good For The Game
Makes miners bring more ore in a fun way.
## Changelog
🆑 Fikou, Zonespace, Arcane for voicing
add: The mining vendor now has a style meter. This meter gauges your
style points and uses them to improve your ore yield.
/🆑
---------
Co-authored-by: Fikou <23585223+Fikou@ users.noreply.github.com>
* Miner Style Points 2: Style on Everyone
---------
Co-authored-by: Zonespace <41448081+Zonespace27@users.noreply.github.com>
Co-authored-by: Fikou <23585223+Fikou@ users.noreply.github.com>
* Refactors sheet crafting to better support directional construction (#74572)
## About The Pull Request
0426f7ddba/code/game/objects/items/stacks/stack.dm (L449)
Ok, but can we not?
This PR refactors sheet crafting to generalize all the cases that were
previously locked behind grille/window type checks and such. In their
stead there are bitflags that can be set to achieve certain behaviors.
All the behavior from before should be preserved, but now it can be
extended to other items. E.g. if you want a railing that can be crafted
underneath directional windows, or an item that behaves like a grille
does--it's just a matter of setting the right obj_flags for it now.
This makes it very simple and painless to add new recipes that use
directional crafting! It's all modular now.
<details><summary>Details</summary>
---
### What I've done:
-Eliminated all the type checks, instead it will now be handled by
object flags and recipe vars, making for a much more configurable
system.
-Added two new obj_flags: `BLOCKS_CONSTRUCTION_DIR` and
`IGNORE_DENSITY`.
-Additionally, I renamed the existing flag `NO_BUILD` to
`BLOCKS_CONSTRUCTION`.
-Changes the proc `valid_window_location` to `valid_build_direction`,
and makes it work for things other than windows.
-Removed a deprecated `window_checks` var from the stack_recipe datum.
-Added three more vars to the stack_recipe datum: `check_direction` and
`check_density`, `is_fulltile`
-Decoupled `on_solid_ground` from the object density check. Now you can
set those separately, allowing you to make recipes that forbid/allow
building things over other things while in space.
---
### What the new flags do:
`BLOCKS_CONSTRUCTION` works as before---prevents objects from being
built on the object. I felt that the previous name was not descriptive
enough, you should know exactly what it does just from looking at the
name.
_example: dna scanner_
`BLOCKS_CONSTRUCTION_DIR` -- setting this on an object will prevent
objects from being built on it when their directions are the same.
_example: directional windows, windoors, railings_
`IGNORE_DENSITY` -- setting this on an object will cause its density to
be ignored when performing the construction density check. This could
have other potential uses as well in the future.
_example: grilles, directional windows, tables_
These three flags cover all the bases for the types of items that are
currently craftable, so there is no more need for any type checking or
weird snowflake window checks. Simply set the appropriate flag and it'll
work as you would expect.
---
### What the recipe vars do:
`check_direction` tells the recipe to check if there's something in that
direction with the `BLOCKS_CONSTRUCTION_DIR` flag set.
`check_density` tells the recipe to run the density check when set. This
is true by default. There are very few items in the game that currently
have this set to false--namely grilles. Setting this to false will make
it so that the object can be constructed regardless of what is in that
tile (unless `one_per_turf` is also set, which will make it so that you
can't craft the same thing twice in the same turf).
`is_fulltile` is used for fulltile windows, but it doesn't necessarily
have to be--you can give this to any recipe and it will adopt the same
properties as that of the fulltile window. Basically they have a special
case where they shouldn't be able to be built over directional
constructions, where normally things would be able to be. Setting this
makes check_direction true as well.
---
### In summary:
Sheet crafting still works just as it did before. But the backend of it
has gotten a glow up and will be able to more easily support new
behaviors.
</details>
## Why It's Good For The Game
This makes the crafting system much more flexible to add recipes to, and
will prevent bad code practices of stacking more conditionals down the
line whenever someone wants to add an item that behaves like grilles or
directional windows in how they are constructed.
It had to be done. Those window checks were a mess.
## Changelog
🆑
qol: added fifty stack versions of remaining glass sheet stacks for ease
of debugging
refactor: refactored sheet crafting to better support directional
constructions that aren't windows
/🆑
---------
Co-authored-by: san7890 <the@ san7890.com>
* Refactors sheet crafting to better support directional construction
* fex
* https://github.com/Skyrat-SS13/Skyrat-tg/pull/20636
---------
Co-authored-by: Bloop <vinylspiders@gmail.com>
Co-authored-by: san7890 <the@ san7890.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Let there be (held) light! Adds directional flashlight sprites, and many new inhand icons for various light objects
* fixes
---------
Co-authored-by: Bloop <vinylspiders@gmail.com>
Co-authored-by: ghost sheep <sheepwiththemask@gmail.com>
* The North Star Expeditionary Vessel - A Second Wind (#74371)
## About The Pull Request
A new map for TGstation, in the works! It has 4 fucking Z levels, a
massive expansive maintenance with unique designs, and some unique code
features in the works.
To Do:
- [x] Update the Map to Modern TG
- [x] Local Tests
- [x] Work on Map Optimizations
- [x] Run Live Tests
Fikou has greatly helped with creating an important flavour aspect of
this map, Trek Uniforms on anyone who joins! See the forum thread for
more. This includes the framework for innate station traits, station
traits loaded as long as it's in a map's json
Here's the forum dev thread there are screenshots there.
https://tgstation13.org/phpBB/viewtopic.php?p=657252#p657252
### Mapping March
Ckey to receive rewards: Cheshify
## Why It's Good For The Game
So, this is the North Star. An effort taking multiple mappers and of 9~
months of hard work. This map was not initially designed for TGstation,
but always designed for TGstation code. The process of retooling the map
for TGstation was an absolute joy and I feel like the map definitely has
it's niche as a massive and unique experience for it's players.
I adore this map, it's gorgeous, has a unique aesthetic, and a number of
very funny interactions with multi-Z. The PR comes packed with unique
mechanics for future mappers (innate station traits!), a number of
map-fitting shuttles, and a fun spacefaring uniform gimmick for the
crew.
**This is my second attempt at bringing this map into rotation. It was
initially closed due to concerns about maptick and performance, as I
wasn't willing to push for a map to be added to the repository if it
didn't function to my own standards. I've been informed by a number of
coders far better than I that optimizations are arriving and enroute, so
I think it's time to dust her off and set sail for another journey.**
**Quick Disclaimer: Due to some design decisions disagreed upon by the
headcoder team and myself, the map will not be featuring unique
roundstart uniforms, and despite my design intentions, the innate
station trait features will be shelved for now.**
## Changelog
🆑 Cheshify, Fikou, Blue-Berry, Zytolg, InfiniteGalaxies, Striders,
Sylphet, Riggle, Soal, Andry, Crit, Deranging, and Pumpkin0.
add: Nanotrasen's Newest Exploratory Vessel is now available! Meet the
North Star!
add: More landmines, and a landmine random spawner.
add: energy barriers now have a regenerative subtype, fit for permanent
installations.
code: Raised the number of possible level render to 4, check your
preferences if needed to be reduced.
/🆑
---------
Co-authored-by: Fikou <23585223+Fikou@ users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* The North Star Expeditionary Vessel - A Second Wind
---------
Co-authored-by: Cheshify <73589390+Cheshify@users.noreply.github.com>
Co-authored-by: Fikou <23585223+Fikou@ users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Gives plasmamen proper masks depending on their job. (#74468)
## About The Pull Request
Adds gasmasks plasma filter subtypes for sechailer, explorer and atmos.
Atmosians won't have any updates, it's just to fix ERP Constructor
Plasmaman loadout spawning with mask that won't allow you to breath.
And so med plasmamen will have medical masks. There will be sechailers
for sec (except for the detective). And the miners will have explorer
masks.
Oriented on job_boxes and what jobs spawn with which boxes.
## Why It's Good For The Game
Some love for living plasma mold. And i just think that it should be
this way.
## Changelog
🆑
add: Plasmamen will now spawn with proper masks depending on the job.
/🆑
* Gives plasmamen proper masks depending on their job.
---------
Co-authored-by: Helg2 <93882977+Helg2@users.noreply.github.com>
* makes cursed katana combos into a generic component (#74543)
## About The Pull Request
what the title says
also the katana's dark cloak move now has some vfx cause i figured why
not
## Why It's Good For The Game
this means anyone can give any weapon combos :D
## Changelog
* makes cursed katana combos into a generic component
---------
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
* Reagent soup / Soup rework / Stoves - A kitchen expansion
* fixes that stuff
* puts the range stove on maps that sohuld have it
* fixes some paths that don't exist anymore
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Paxilmaniac <paxilmaniac@gmail.com>
* Rebalances a vast oversight with one of the game's weapons (#74283)
## About The Pull Request
Makes sure the game is fairly balanced again.
## Why It's Good For The Game
Honestly I'm surprised this weapon went unchanged for so long with no
downsides.
## Changelog
🆑 Wallem
balance: Fixes a glaring oversight with the entrenching tool's
balancing.
/🆑
* Rebalances a vast oversight with one of the game's weapons
---------
Co-authored-by: Wallem <66052067+Wallemations@users.noreply.github.com>
* fixes heck suit hiding boots and gloves (#74131)
the armor's worn icon doesnt cover boots or gloves so when you wear it
over them you look all messed up
* fixes heck suit hiding boots and gloves
---------
Co-authored-by: SMOSMOSMOSMOSMO <95004236+SmoSmoSmoSmok@users.noreply.github.com>
* Audits usage of isanimal() vs isanimal_or_basic_mob() (#74029)
## About The Pull Request
There's a couple of open issues which fix places where only simple
animals were considered, but they are doing it piecemeal.
I decided to just go through every instance of `isanimal` or
`subtypesof(mob/living/simple_animal)` I could find, identify which
should also affect basic mobs, and fix them.
I left out the two others which are already in PR, I'm not stealing your
GBP.
Fixes https://github.com/tgstation/tgstation/issues/68881
## Why It's Good For The Game
Consistency, mostly.
As far as I can tell all of these things _should_ have effected basic
mobs, but didn't.
This fixes a fair number of bugs but also they're bugs that nobody
noticed or reported.
There are a couple of places I did not update which will need updating
in future. These are:
- Dextrousness checks, because basic mobs don't have that yet.
- The Charge cooldown action, because frankly I couldn't tell what it
was trying to do.
alright here goes
## Changelog
🆑
fix: Carp will once again be healed from being near carp rifts
fix: Sepia slime cores and the rewind camera now work on Ian
fix: Sapient ridden carp (or cows) can throw off their riders by shoving
them, or by performing the spin emote.
fix: Giant Spider AI will be disabled by the timestop spell
fix: Ian can eat envirochow
fix: Mice, Frogs, and Cockroaches will no longer set off bear traps
fix: You can put a macrobomb implant into Cayenne (or Ian)
fix: Ian will now recognise that being squeezed by a cyborg is a nice
hug
fix: The player panel will tell admins if you're currently a corgi
fix: The staff of storms deals massive damage to Bileworms and Giant
Spiders
fix: Ian will whimper if forced to scream
fix: Slimes can consume space carp
fix: Mice can be captured in xenoballs
fix: You can use pacifying potions on Giant Spiders
fix: Sgt Araneus can be fitted with a xenobiological radio implant
fix: Sapient corgis no longer count as living players for the purpose of
highlander escape objectives
fix: The random sentience event can now target corgis and sergeant
araneus
add: The random sentience event can target a wider array of farm animals
fix: Petsplosion wizard event can target corgis
add: Petsplosion wizard event will now target farm animals and
mothroaches
fix: The colossus possession crystal can now actually possess the
cockroach it spawns, does not kill you instantly upon ending possession
/🆑
* Audits usage of isanimal() vs isanimal_or_basic_mob()
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* Splits mutant_bodyparts.dmi into several subfiles. (#71408)
Splits the `mutant_bodyparts.dmi` file up, as was suggested, but not
implemented, in #69302.
The following new files were created in the `icons\mob\species` folder,
containing the listed sprites:
- `lizard\lizard_misc.dmi`: Snouts, horns, frills, and body markings.
Anything I didn't feel needed an entire file to itself.
- `lizard\lizard_spines.dmi`: Lizard spines, both animated and not.
- `lizard\lizard_tails.dmi`: Lizard tails, both animated and not.
- `human\cat_features.dmi`: Felinid ears and tails.
- `monkey\monkey_tail.dmi`: The monkey tail.
- `mush_cap.dmi`: The lone mushperson cap, so easily forgotten.
Additionally, I moved `wings.dmi` from `mob\clothing` to `mob\species`.
I'm not sure what it was doing there.
`mutant_bodyparts.dmi` was something of a mess, with parts from four
different species thrown together haphazardly. It probably made sense in
earlier days when "mutant humans" were few and far between, but
splitting it up makes it more intuitive to find these sprites, and
brings it in line with other species - namely, moths. It also means that
any future sprites of these types added will not bloat an oversized file
even more.
Moving the wings file to the species folder just makes sense, because
wings are not a type of clothing.
🆑
refactor: Removed mutant_bodyparts.dmi and distributed its sprites in a
more sensible and granular manner.
/🆑
* External Organ Rework: new bodypart_overlay system (#72734)
Bodypart overlays are now drawn by the new /datum/bodypart_overlay
datum.
External organs no longer draw anything and instead add a special
/datum/bodypart_overlay/mutant to the bodypart, which draws everything
Makes it way easier to add custom overlays to limbs, since the whole
system is now modularized and external organs are just one
implementation of it
I haven't moved anything but external organs to this new system, I'll
move eyes, bodymarkings, hair, lipstick etc to this later
New pipeline is as follows:
- External organ added to limb
- External organ adds /datum/bodypart_overlay/mutant to limb to
bodypart_overlays
- Limb updates its icon, looks for all /datum/bodypart_overlay in
bodypart_overlays
- Very cool new overlay on your limb!
closes#71820🆑
refactor: External organs have been near-completely refactored.
admin: Admin-spawned external organs will load with a random icon and
color
fix: fixes angel wings not working for non-humans (it was so fucking
broken)
fix: fixes external organs being invisible if they werent initialized
with a human
/🆑
External organs are cool but are pretty limited in some ways. Making
stuff like synthetic organs is kinda fucked. I tried and it was dogshit.
Now you can just give an icon state and icon and you're good (using
/datum/bodypart_accessory/simple)
Stuff like eyes, cat ears and hair seem like good choices for extorgans,
but don't quite work for it because their icons work a lot differently.
This solves for it completely since any organ (or object or whatever)
can add it's own icon to a bodypart.
Want to add an iron plate to someones head? Go ahead. Want a heart to
stick out of someones chest? No problem.
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Makes the whole thing compile, although it most likely doesn't work
* Whoopsie daisy
* Now it's starting to work
* ok monkey
* Fixes tails some more
* Moth wings should be wings not moth wings
* Podpeople hair, yeah.
* Okay no more handle_mutant_bodyparts()
* Removed an useless variable from is_hidden()
* Fixes some more can_draw_on_bodypart (I'm gonna have to fix it upstream too)
* Removes the second useless argument of is_hidden()
* No, cat tails are no longer allowed to be snowflake
* Removes some useless variables from humans
* Whoops I forgot to commit this one
* How did I miss this one?
* Okay, yeah, tails and some other stuff show up now. Pod people hair too. Just many of them don't. Good enough for today.
* Okay so after a lot of pain and suffering, many mutant_bodyparts are now functional
* Everything works, except for ears, some of the taur layering, and moth markings (which never worked it seems)
* Alright skintones seem to work rather well now(?)
* Okay, my bad, now they do
* Moth markings can't be selected and won't be added anymore (since they're broken and integrated into the regular markings system anyway)
* Spines are no longer just matching the color of the limb they're attached to
* Moves taur organ and bodypart_overlay out of the sprite_accessory file for taurs, and fixes the taur rendering
* Linters moment
* Alright, spines are working and overlaying properly now
They just need to have a FRONT overlay for the /tg/ ones if we want them to display above the lizard tails, we already have that for vox spines thankfully.
* Disables moth_markings for good
* Fixes some rendering bugs
* Makes ears work (almost, rest of the code has MODsuit stuff in it too :( )
* Made the MODsuit overlays work :)
* Fixed horns and spines
* Fixes all of the screenshot tests
* Removes the Body Markings option from Appearances, use Augments+ instead (because that one works and is just better)
* Bye bye handle_mutant_bodyparts(), I won't miss you :)
* Forgot to take this out, whoops
* Fixes the moth antennae being unticked
* Removes some commented code in a modular file
* Fixes part of the create_and_destroy unit test
* Fixes a pretty big issue that caused some sprite_accessories to be removed from the global list because of the alter_form action (deep copies ftw)
* Fixes the runtimes related to pod_hair
* Gives the vox a better look in the prefs menu
* Fixes the appearance of functional wings
* Makes synths able to access their robotic wings
* Podpeople don't cause runtimes during CI anymore
* Fixes the random appearance of locked functional wings
* Fixed cat and lizard tails using the /tg/ sprites (we have slightly modified ones)
* Fixes the coloring on multi-colored sprites
* Fixes the code for the screenshot of the mammal screenshots and preview, so it has a tail
* Fixes the screenshot tests for a few species
* Fixes tails going invisible when wagging
* Fixes a runtime with horns
* Fixes showing/hiding mutant bodyparts not working at all
* (Hopefully) fully fixes all the issues related to extra and extra2-related icon_states.
* Fixes synth stuff and starts working on pod hair again
* I DID IT PODPEOPLE HAVE HAIR AGAIN
* Fixes the podpeople hair showing up on more than just podpeople
* Fixes the IPC screens showing up on species outside of synthetics
* Fixes a runtime in the pod_hair and the synth_screen's apply_to_human
* Updates the screenshots for podpeople and synths
* Fixes an issue with a certain type of organs
* Fixes another runtime, whoops
* Fixes the markings from /tg/'s Body Markings not being available in our markings system
* Re-adds support for taur-variants of certain mutant bodyparts
* Hopefully fixes a few more runtimes
* Adds some debug variable in the code for now, likely to be removed later if really necessary. This will make my life easier.
* Whoops, that needed to be backwards. :clown:
* Fixes the top snouts not rendering at all
* Fixes the issues where bodytypes weren't handled properly, and thus snouts were getting squished
* Fixes the weird placement of the Xeno Head Emissives in the prefs menu
* Removes a no-longer-necessary override of post_set_preference() in the limbs_and_markings middleware
* Reverts an unnecessary SKYRAT EDIT inside of commented out code
* No longer creates a new body every time we change prefs in the prefs menu, we reusing now lads
I know there's commented out code but I'm going to remove that in another commit
* Removed some more dead code.
* Fixes jellyfish ears being all white
* Fixes plasmaman limbs not displaying because I accidentally hardcoded the limb_id for all augments to "robotic"
---------
Co-authored-by: lizardqueenlexi <105025397+lizardqueenlexi@users.noreply.github.com>
Co-authored-by: Time-Green <timkoster1@hotmail.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Reworks sabotage progression traitor objective (#73750)
## About The Pull Request
This one is a little bit of a more abstract change than my last traitor
objective rebalancing PR.
The idea here is that I think that the objectives which have you
sabotage a frequently used machine (lathes or the ORM, but we can maybe
expand it to others following this?) are potentially pretty good but
limitations in how the objective are tracked mean that people go about
them in a boring way which rarely inconveniences anyone.
I have reworked these objectives so that you can choose to apply a
provided item to the machine over 10 seconds. The next interaction
following this (clicking on it, or in the case of the ORM loading any
ore into it) will cause the machine to explode, destroying itself and
lightly damaging people nearby (explosion damage is... variable, but
it's a light explosion so it won't instantly kill anyone).
There is a 0.5 second grace period between the bomb triggering and the
explosion actually happening, which players can use to perform some kind
of tactical reaction or simply to feel regret.
Here's a video:
https://www.youtube.com/watch?v=xNIaHsA9YFE
Trapped machines will intermittently beep, though at a volume which is
hard to detect from more than two tiles away, and can be defused by
using a screwdriver on the machine.
If you choose to do this then you will get a little bonus to TC and
reputation, but only if the trap is successfully sprung. This means that
sabotaging a machine in an empty department is unlikely to lead to quick
success.
You can also still do it with screwdriver and crowbar way if you are
boring but this means you will only get reputation and not any
telecrystals.
The two objectives to destroy a radio server or the research machine
remain as they were.
Also I refactored how we set which machines are targets for these
objectives so it doesn't iterate over every machine in the world every
time.
## Why It's Good For The Game
Traitor objectives (and antagonist objectives in general) should:
- Present you with a somewhat engaging task
- Encourage you to interact with at least one other player (at least by
"attempting to sneak past them")
- Move the state of the round forward in some way, usually by creating
inconvenience for at least one other person
Prior to this change you could, and people often did, complete this
objective by accessing a machine that you already _have_ access to,
using a screwdriver and crowbar on it, and then reassembling it.
This prompts interaction with nobody, and inconveniences nobody.
Following this change people will be encouraged to:
- Actually destroy the machine.
- Probably harm somebody.
- Potentially cause some collateral damage.
- Make loud sounds and flashing lights to delight people of all ages.
Even if you opt to set the device in a little-used department and then
blow yourself up, that will prompt you to go and interact with someone
in medbay and will also look pretty suspicious in a way that's much
harder to track with the previous objective.
Also I might reuse this component again in the future, you never know.
## Changelog
🆑 Jacquerel, sprite by J(Clearly Lying)
balance: Traitor objectives which ask you to destroy lathes or the ORM
provide an optional bonus if you _booby trap_ the machine using a
provided tool. This causes the machine to explode the next time it is
interacted with.
balance: Performing the objective without rigging the machine to explode
awards no TC, using it awards more TC than it did previously.
/🆑
* Reworks sabotage progression traitor objective
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Adds a stack_trace for emissives with invalid icon_states, fixes all that appeared roundstart (#73678)
## About The Pull Request
So, this spiraled from one missing icon being fixed to an entire check
for said icons.
Several icon files no longer use error icons because its assumed that
the checks will handle any missing ones, but the checks don't apply to
emissives nor overlays at all. This led to the radsuit having an
emissive but no icon_state for it - a relic of the old radsuit. This was
only noticed because of a downstream with an error icon appearing for
it...
I was curious how many were actually having the same issue, so I made a
small little stack_trace in the mutable_appearance proc.
There were like, 2k. Lots of them were icons named, like, "transparent"
or "blank" too...
I moved that check to the emissives proc because I semi-understand that
system so could actually fix it, and it moved to around fourty
roundstart. Much more achievable.
(The error usually has more info if you click on it, including the item
that caused it. I dunno how to add that to the check itself because of
where it's located, though.)
This fixes all the ones I could find, including...
Nonexistant icons that shouldn't be adding emissives on:
- Empty Barsign
- Radsuit
- Mass Driver Controllers
- Telescreens
- Aux Base Consoles
- PanDEMIC
- Kobayashi computer (holodeck)
- Abductor camera console
- Syndie drop pod
- BSA controller
Entirely missing icons on:
- Pwr Game Vendor (this was just misnamed)
- Generic Soda Vendor
- Engivend
- Security Laptop (proud of this one.,.,)
There are no doubt more of them hidden about, but I don't really know
what I'm doing... If there's a check that'd be better than this, please
review telling me what to change <3
## Why It's Good For The Game
Fixes missing icons, fixes attempts to add icons where we don't need
them, and adds a check to help fix more of the two issues as they occur.
## Changelog
🆑
fix: fixed missing emissives on the Engivend, Pwr-Game Soda, and generic
Soda vendors. Also fixed the seclaptop having no valid screen icon!
fix: fixed a few items trying to apply emissives when they shouldn't.
code: added a stack_trace for emissives with missing icon states.
/🆑
* Adds a stack_trace for emissives with invalid icon_states, fixes all that appeared roundstart
* Update cryopod.dm
---------
Co-authored-by: OrionTheFox <76465278+OrionTheFox@users.noreply.github.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Nightvision Rework (In the name of color) (#73094)
Relies on #72886 for some render relay expansion I use for light_mask
stuff.
Hello bestie! Night vision pissed me off, so I've come to burn this
place to the ground.
Two sections to discuss here. First we'll talk about see_in_dark and why
I hate it, second we'll discuss the lighting plane and how we brighten
it, plus introducing color to the party.
https://www.byond.com/docs/ref/#/mob/var/see_in_dark
See in dark lets us control how far away from us a turf can be before we
hide it/its contents if it's dark (not got luminosity set)
We currently set it semi inconsistently to provide nightvision to mobs.
The trouble is stuff that produces light != stuff that sets luminosity.
The worst case of this can be seen by walking out of escape on icebox,
where you'll see this
Snow draws above the lighting plane, so the snow will intermittently
draw, depending on see_in_dark and the luminosity from tracking lights.
This would in theory be solvable by modifying the area, but the same
problem applies across many things in the codebase.
As things currently stand, to be emissive you NEED to have a light on
your tile. People are bad at this, and honestly it's a bit much to
expect of them. An emissive overlay on a canister shouldn't need an
element or something and a list on turfs to manage it.
This gets worse when you factor in the patterns I'm using to avoid
drawing lights above nothing, which leads to lights that should show,
but are misoffset because their parent pixel offsets.
It's silly. We do it so we can have things like mesons without just
handing out night vision, but even there the effect of just hiding
objects and mobs looks baddddddd when moving. It's always bothered me.
I'll complain about mesons more later, but really just like, they're too
bright as it is.
I'm proposing here that rather then manually hiding stuff based off
distance from the player, we can instead show/hide using just the
lighting plane. This means things like mesons are gonna get dimmer, but
that's fine because they suck.
It does have some side effects, things like view() on mobs won't hide
stuff in darkness, but that's fine because none actually thinks about
view like that, I think.
Oh and I added a case to prevent examining stuff that's in darkness, and
not right next to you when you don't have enough nightvision, to match
the old behavior `see_in_dark` gave us.
Now I'd like to go on a mild tangent about color, please bare with me
You ever walk around with mesons on when there's a fire going, or an
ethereal or firelocks down.
You notice how there isn't really much color to our lights? Doesn't that
suck?
It's because the way we go about brighting lighting is by making
everything on the lighting plane transparent.
This is fine for brightening things, but it ends up looking kinda crummy
in the end and leads to really washed out colors that should be bright.
Playing engineer or miner gets fucking depressing.
The central idea of this pr, that everything else falls out of, is
instead of making the plane more transparent, we can use color matrixes
to make things AT LEAST x bright.
https://www.byond.com/docs/ref/#/{notes}/color-matrix
Brief recap for color matrixes, fully expanded they're a set of 20
different values in a list
Units generally scale 0-1 as multipliers, though since it's
multiplication in order to make an rgb(1,1,1) pixel fullbright you would
need to use 255s.
A "unit matrix" for color looks like this:
```
list(1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1,
0, 0, 0, 0
)
```
The first four rows are how much each r, g, b and a impact r, g, b and
well a.
So a first row of `(1, 0, 0, 0)` means 1 unit of r results in 1 unit of
r. and 0 units of green, blue and alpha, and so on.
A first row of `(0, 1, 0, 0)` would make 1 red component into 1 green
component, and leave red, blue and alpha alone, shifting any red of
whatever it's applied to a green.
Using these we can essentially color transform our world. It's a fun
tool. But there's more.
That last row there doesn't take a variable input like the others.
Instead, it ADDS some fraction of 255 to red, green, blue and alpha.
So a fifth row of `(1, 0, 0, 0)` would make every pixel as red as it
could possibly be.
This is what we're going to exploit here. You see all these values
accept negative multipliers, so we can lower colors down instead of
raising them up!
The key idea is using color matrix filters
https://www.byond.com/docs/ref/#/{notes}/filters/color to chain these
operations together.
Pulling alllll the way back, we want to brighten darkness without
affecting brighter colors.
Lower rgb values are darker, higher ones are brighter. This relationship
isn't really linear because of suffering reasons, but it's good enough
for this.
Let's try chaining some matrixes on the lighting plane, which is bright
where fullbright, and dark where dark.
Take a list like this
```
list(1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1,
-0.2, -0.2, -0.2, 0
)
```
That would darken the lighting a bit, but negative values will get
rounded to 0
A subsequent raising by the same amount
```
list(1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1,
0.2, 0.2, 0.2, 0
)
```
Will essentially threshold our brightness at that value.
This ensures we aren't washing out colors when we make things brighter,
while leaving higher values unaffected since they basically just had a
constant subtracted and then readded.
You may have noticed, we gain access to individual color components
here.
This means not only can we darken and lighten by thresholds, we can
COLOR those thresholds.
```
list(1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1,
0.1, 0.2, 0.1, 0
)
```
Something like the above, if applied with its inverse, would tint the
darkness green.
The delta between the different scalars will determine how vivid the
color is, and the actual value will impact the brightness.
Something that's always bothered me about nightvision is it's just
greyscale for the most part, there isn't any color to it.
There was an old idea of coloring the game plane to match their lenses,
but if you've ever played with the colorblind quirk you know that gets
headachey really fast.
So instead of that, lets color just the darkness that these glasses
produce.
It provides some reminder that you're wearing them, instead of just
being something you forget about while playing, and provides a reason to
use flashlights and such since they can give you a clearer, less tinted
view of things while retaining the ability to look around things.
I've so far applied this pattern to JUST headwear for humans (also those
mining wisps)
I'm planning on furthering it to mobs that use nightvision, but I wanted
to get this up cause I don't wanna pr it the day before the freeze.
Mesons are green, sec night vision is red, thermals orange, etc.
I think the effect this gives is really really nice.
I've tuned most things to work for the station, though mesons works for
lavaland for obvious reasons.
I've tuned things significantly darker then we have them set currently,
since I really hate flat lighting and this system suffers when
interacting with it.
My goal with these is to give you a rough idea of what's around you,
without a good eye for detail.
That's the difference between say, mesons, and night vision. One helps
you see outlines, the other gives you detail and prevents missing
someone in the darkness.
It's hard to balance this precisely because of different colored
backgrounds (looking at you icebox)
More can be done on this front in future but I'm quite happy with things
as of now
I have since expanded to all uses of nightvision, coloring most all of
them.
Along the way I turned some toggleable nightvision into just one level.
Fullbright sucks, and I'd rather just have one "good" value.
I've kept it for a few cases, mostly eyes you rip out of mobs.
Impacted mobs are nightmares, aliens, zombies, revenants, states and
sort of stands.
I've done a pass on all mobs and items that impact nightvision and added
what I thought was the right level of color to them. This includes stuff
like blobs and shuttle control consoles
As with glasses much of this was around reducing vision, though I kept
it stronger here, since many of these mobs rely on it for engaging with
the game
<details>
<summary>
Technical Changes
</summary>
filter transitions.
Found this when testing this pr, seemed silly.
This avoids dumbass overlay lighting lighting up wallmounts.
We switch modes if some turfflags are set, to accomplish the same thing
with more overhead, and support showing things through the darkness.
Also fixes a bug where you'd only get one fullscreen object per mob, so
opening and closing a submap would take it away
Also also fixes the lighting backdrop not actually spanning the screen.
It doesn't actually do anything anymore because of the fullscreen light
we have, but just in case that's unsued.
Needs cleanup in future.
color with a sprite
This is to support the above
We relay this plane to lighting mask so openspace can like, have
lighting
vision goggles and such
Side affect of removing see_in_dark. This logic is a bit weak atm, needs
some work.
It's a dupe of the nightvision action button, and newly redundant since
I've removed all uses of it
trasnparent won't render
These sucked
Also transparent stuff should never render, if it does you'll get white
blobs which suck
</details>
Videos! (Github doesn't like using a summary here I'm sorry)
<details>
Demonstration of ghost lighting, and color
https://user-images.githubusercontent.com/58055496/215693983-99e00f9e-7214-4cf4-a76a-6e669a8a1103.mp4
Engi-glass mesons and walking in maint (Potentially overtuned, yellow is
hard)
https://user-images.githubusercontent.com/58055496/215695978-26e7dc45-28aa-4285-ae95-62ea3d79860f.mp4
Diagnostic nightvision goggles and see_in_dark not hiding emissives
https://user-images.githubusercontent.com/58055496/215692233-115b4094-1099-4393-9e94-db2088d834f3.mp4
Sec nightvision (I just think it looks neat)
https://user-images.githubusercontent.com/58055496/215692269-bc08335e-0223-49c3-9faf-d2d7b22fe2d2.mp4
Medical nightvision goggles and other colors
https://user-images.githubusercontent.com/58055496/215692286-0ba3de6a-b1d5-4aed-a6eb-c32794ea45da.mp4
Miner mesons and mobs hiding in lavaland (This is basically the darkest
possible environment)
https://user-images.githubusercontent.com/58055496/215696327-26958b69-0e1c-4412-9298-4e9e68b3df68.mp4
Thermal goggles and coloring displayed mobs
https://user-images.githubusercontent.com/58055496/215692710-d2b101f3-7922-498c-918c-9b528d181430.mp4
</details>
I think it's pretty, and see_in_dark sucks butt.
<!-- 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: The darkness that glasses and hud goggles that impact your
nightvision (think mesons, nightvision goggles, etc) lighten is now
tinted to match the glasses. S pretty IMO, and hopefully it helps with
forgetting you're wearing X.
balance: Nightvision is darker. I think bright looks bad, and things
like mesons do way too much
balance: Mesons (and mobs in general) no longer have a static distance
you can see stuff in the dark. If a tile is lit, you can now see it.
fix: Nightvision no longer dims colored lights, instead simply
thresholding off bits of darkness that are dimmer then some level.
/🆑
* modular edits
* see_in_dark
* [MIRROR] Adds a unit test to detect double stacked lights [MDB IGNORE] (#19564)
* Adds a unit test to detect double stacked lights
* we really need to get that night vision pr done
* lints fixes
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Paxilmaniac <paxilmaniac@gmail.com>
* Update augments_eyes.dm
* Update augments_eyes.dm
* eeee
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: SkyratBot <59378654+SkyratBot@users.noreply.github.com>
Co-authored-by: Paxilmaniac <paxilmaniac@gmail.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
