## About The Pull Request
I thought, "Hey it'd be neat if glass stuff shattered when thrown
around, wouldn't it?" And thus, shattering became a component. Though it
only applies to any subtype of object, its still more than enough for my
purposes. Plates will still shatter as normal before, but if for any
reason a glass toolbox, or glass statue block, anything glass you get
the idea, is thrown? Shards everywhere. Oh no, our table, its broken.
## Why It's Good For The Game
Something shattering on impact from being thrown or dropped a zlevel is
hilarious, and it'd be even funnier to be able to extend this behavior
to other objects as well. Finally we can relive every comedy movie ever
where some construction workers drop a comically large glass object on
someone from two floors up.
Ladies, Gentlemen, Gamers. You're probably wondering why I've called you
all here (through the automatic reviewer request system). So, mineral
balance! Mineral balance is less a balance and more of a nervous white
dude juggling spinning plates on a high-wire on his first day. The fact
it hasn't failed after going on this long is a miracle in and of itself.
This PR does not change mineral balance. What this does is moves over
every individual cost, both in crafting recipes attached to an object
over to a define based system. We have 3 defines:
`sheet_material_amount=2000` . Stock standard mineral sheet. This being
our central mineral unit, this is used for all costs 2000+.
`half_sheet_material_amount=1000` . Same as above, but using iron rods
as our inbetween for costs of 1000-1999.
`small_material_amount=100` . This hits 1-999. This covers... a
startlingly large amount of the codebase. It's feast or famine out here
in terms of mineral costs as a result, items are either sheets upon
sheets, or some fraction of small mats.
Shout out to riot darts for being the worst material cost in the game. I
will not elaborate.
Regardless, this has no functional change, but it sets the groundwork
for making future changes to material costs much, MUCH easier, and moves
over to a single, standardized set of units to help enforce coding
standards on new items, and will bring up lots of uncomfortable balance
questions down the line.
For now though, this serves as some rough boundaries on how items costs
are related, and will make adjusting these values easier going forward.
Except for foam darts.
I did round up foam darts.
Adjusting mineral balance on the macro scale will be as simple as
changing the aforementioned mineral defines, where the alternative is a
rats nest of magic number defines. ~~No seriously, 11.25 iron for a foam
dart are you kidding me what is the POINT WHY NOT JUST MAKE IT 11~~
Items individual numbers have not been adjusted yet, but we can
standardize how the conversation can be held and actually GET SOMEWHERE
on material balance as opposed to throwing our hands up or ignoring it
for another 10 years.
## About The Pull Request
Material tiles used to reference an incorrect filename for some of their
footstep audio. This resulted in barefoot, claw, and heavy footsteps not
making any noise on them, as well as triggering a Runtime error in the
logs with each step taken. The code for constructing these file names
has been corrected, and now properly paths to the appropriate sounds.
Closes#70145
## Why It's Good For The Game
These changes improve stability by reducing unnecessary Runtimes, and
restore footstep noise to Material tiles for many creatures/scenarios.
## Changelog
🆑
fix: Material tile floors now make noise when walked on by
bare/claw/heavy feet
/🆑
## About The Pull Request
spawnDebris was being overridden by almost every type of window, I've
set up some new vars for it to pull shard and its debris decal from so
spawnDebris only needed to be set up once (+ once more for paper windows
which are unique).
Fixes an issue with reinforced plasma glass windows dropping regular
glass when broken.
Fixes an oversight where tram windows were dropping only 1 rod instead
of 2 and dropping glass sheets instead of shards.
Cleans up tram window code a bunch.
## Why It's Good For The Game
Fixes several issues, cleans up code and cuts down on a lot of repeat
code.
## Changelog
🆑
fix: Reinforced plasma windows will now drop plasma glass instead of
regular glass when broken.
fix: Tram windows drop the correct number of rods and a shard when
broken instead of a sheet.
code: Removed a ton of duplicate vars in tram window code and
re-organize the file slightly.
refactor: spawnDebris has been un-hardcoded and all (but one) override
of it has been removed.
/🆑
<!-- 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
Adds support to underlays to realize_overlays
Ensures decals properly handle plane offsets
Fixes space lighting double applying if it's changeturf'd into. this
will be important later
Makes solar vis_contents block emissives as expected
Moves transit tube overlays to update_overlays, adds emissive blockers
to them
#### Adds render steps
An expansion on render_target based emissive blockers.
They allow us to hijack an object's appearance and draw it somewhere
else, or even modify it, THEN draw it somewhere else.
They chain quite nicely
Fixes shuttles deleting z holder objects
#### Makes space emissive, makes walls and floors block emissives
The core idea here goes like this:
We make space glow, and give its overlays some color
This way, the tile and space parallax remain fullbright, along with
anything that doesn't block emissives, but anything that does block
emissives will instead get shaded the color of starlight
This requires a bit of extra work, see later
This is done automatically with render relays, which now support
specifiying layer and color (Need to make an editor for these one of
these days)
The emissive blocking floor stuff requires making a second render plate
to prevent double scaling
Also adds some new layering defines for lighting, and ensures all turf
lights have a layer. We'll get to this soon
#### Makes things in space blue
We color them the same as starlight, by taking advantage of space being
emissive
This means that things in space that block emissive will block it
correctly and be colored blue by the light overlay, but space itself
will remain fullbright
This does require redefining what always_lit means, but nothing but
cordons use that so it's fineee
#### Makes glass above space glow, and some other stuff
Glass tiles that sit above space will now shine light with matching
color to the glasses color. This includes mat tiles.
Glass tiles (not mat because they have no alpha) also only partially
block emissives.
Adds a new proc that uses render steps to acomplish this, essentially
we're cutting out bits below X alpha and drawing what remains as an
emissive.
#### Modifies partial space showing to support glow
Essentially, alongside displaying space as an underlay, we also display
a light overlay colored like starlight.
That starlight overlay gets masked to only be visible in bits that do
not contain any alpha.
We also mask the turf lighting to not go into bits that have no alpha,
to ensure we get the effect we want.
This is done with that lighting layer thing I mentioned earlier.
#### Makes appearance realization's list output ordered
I want it output in order of overlay, sub overlay suboverlay, next
overlay
Need to use insert for that
## Why It's Good For The Game
Pretty!
Also having space be emissive is a very very good way to test for fucked
emissive blockers (If it's broken why are we even drawing the overlay)
I know for a fact mob blockers on lizards and socks are kinda yorked, I
think there's more
<details>
<summary>
Old
</summary>
</details>
<details>
<summary>
New
</summary>
</details>
## 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: Space now makes things in it starlight faintly blue
fix: Glass floors that display space now properly let space shine
through them, rather then hiding it in the dark
add: Glass floors above space now glow faintly depending on their glass
type
/🆑
<!-- 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: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
## About The Pull Request
[Saves 0.2 seconds of init time. 50% of emissive
blockers](8318b648f6)
Emissive blockers are a decent expense during init, even these, which
are the ones that update outside of initialize.
I've inlined them, removed some redundant vars and checks, reduced the
arg count, and shifted some things around. This ends up saving 200ms, or
50% of its total cost.
I also shifted mutable_appearance about a bit. it's not a massive
saving, but it is technically faster
[Prevents a few redundant appearance_updates, saves 0.8 seconds of
init](5475cd778b)
Prequisit info: update_appearance is decently expensive
It's good then to only do it if we have a reason to, right?
Me and moth were shooting the shit about just general init time, and we
came up with the idea of tracking which update_appearances actually
"worked" and which didn't.
That bit comes later, let's enjoy the fruits of that work first
First, holograms were calling update_appearance on process, for almost
no reason.
I patched the one event they don't already "react" to, and then locked
it behind a change decection if.
good for live, doesn't impact init.
Next, decals. If you add a decal to something before it inits, it'll
react to the after successful init signal.
The trouble is the same atom could have its appearance updated from this
MORE then once, since decals can be stacked on tiles, and signal
unregisters don't work once the signal is sent.
So we add a flag to track if we've had this happen to us or not, so it
only happens once.
saves 80 ms
Power! lots of things call power_change on init, often more then once.
We'll update appearance for each of those calls, even if only one is an
actual change.
That's silly, better to track what sort of power we're using for our
appearance and go off that changing
This was taking about 300ms. Really stupid
Icon smoothing. After emissive blockers were added, any change to
something's icon smoothing would lead to an update_appearance call.
Nasty shit, specially cause of walls, which don't even use emissive
blockers.
Ok then, so we'll always update appearance for movables, and will allow
turfs that are interested to hook it manually.
Not many of those anyhow
This is slightly a dev ux thing, but it saves 600ms so I think it's
worth it. Rare case anyway
Telecomms:
telecomm machines were updating appearance on process. This is to cover
for them turning on/off on process.
Better then to just check if on actually changed.
This cost adds up midgame, doesn't impact init tho
Materials:
There's this update_appearance call in material on_apply. it doesn't do
anything.
The logs will lie to you and say it does, but it's just like reapplying
emissives. It doesn't need to exist
Saves like 50ms
Canisters:
Live thing, lots of time wasted updating appearance for no reason, lets
see if we change anything first yes?
[Uses defines to wrap update_appearance for
tracking](4fa82e1c9d)
[Undoes _update_appearance changes, instead reccomends 2 regexes to
use](a8c8fec57a)
I need file and line number for my tracking, so I need to override
update_appearance calls, and also preferably not require every override
of update_appearance to handle dummy file + line args.
So instead, I created a wrapper proc that checks to see if appearanaces
match (they're unique remember, the two of the same visual appearance
will be equivalent)
The trouble is I can't intercept JUST proc calls, or JUST function
definitions with defines. it needs to be both.
So I renamed the /update_appearance proc to /_update_appearance
this way I can capture old uses, and don't need to worry about merge/dev
brain skew
~~It does mean that all update_appearance proc definitions now look
weird tho.
My profiling is leaking into dev ux. I wish I had better templating.~~
**The above is no longer being pr'd**, it's instead just recommended via
a few regexes adjacent to the define.
Smelled wrong anyhow
[Adds a setter for panel_open, so I can update_appearance on
it](cf1df8a69f)
## Why It's Good For The Game
Speed
About The Pull Request
Adds a skillchip to the chef's vendor. This vendor allows the chef to kiss their food to deliver a chef's kiss.
Chef's kissing your food will add the "love" reagent to the food, which makes people much happier when they eat it. Be careful, overdosing on love can cause heart attacks.
Refactors microwaving.
Separates microwaving out of the edible component and makes it its own element, like grillable and bakeable.
Also removes some magic numbers from microwave code.
Code improvements all around baking and grilling code.
Refactors edible component inheritance.
Inheriting the edible component is now a viable way to cleanly add food types, flags, and callbacks. This makes it much much easier to change the values of an edible item without adding hacky signals / procs / getcomponent.
Why It's Good For The Game
Emergent chef gameplay.
Being able to further enhance your food with mood buffs.
Better code.
Changelog
cl Melbert
add: Chefs can now make food with love. They can purchase a skillchip from their vendor which enhances their kiss emote. Using your kiss on food you create will add a special reagent to it which makes it nicer.
refactor: Separated Microwavable from the Edible component, refactored microwave act to accompany this
refactor: Refactored how grilled items are generated
refactor: Refactored how silver slime food items are generated
refactor: Refactored how edible items inherit new edible statuses
code: Removed some magic numbers from microwaves
code: General code improvements for grillable / bakeable / etc
/cl
Ever been bothered by why titanium glass and plastitanium glass do not drop their own shard types? Well this is the perfect PR for you! Titanium and plastitanium glass shards never existed, and it is probably because the person who made glass way back in the day didn't have time to add these shards. Luckily I decided to add them after all this time. Every piece of code created has been carefully considered and copied form other code, so then you know it is good code. Also I added more tags, I looked at the guidelines and found that adding the fix and qol tags probably boosts my pr score so it will get merged.
Creates a wrapper macro for ex_act() and moves the signal and contents explosion calls to there. This way we can ensure the signal is always fired. Also desnowflakes reagents responding to explosions.
Ensures that a signal is always called when the attendant proc is called.
Fixes#62794 (Catwalk Tiles placed on the lower level of tram appear to be on the upper level)
Fixes#57654 (Open Space shading not always applied)
Fixes#53666 (When standing on a glass floor above a light on the Z level below you the light effect is rendered above the character. This makes light have ugly glows on the floors above. This also happens with grills and lattice.)
Transparent turfs, catwalks, and lighting overlays were badly broken with MultiZ issues. This fixes any transparent turf to appear and be on the same z-level if it has the turf_transparent element. Catwalks will appear and be on the same z-level as well. They were initially glitching to top z-levels causing people to walk over an illusion that caused them to fall to their deaths.
After I fixed these issues I noticed that lighting overlays were also glitching to top z-levels, which looked rather strange as there were lights in the middle of rooms and hallways with no supporting walls. Lights now appear under the transparent turfs properly.
The mapping icons for catwalks displayed the wrong icon_state so I fixed that too.
I made a big refactor for transparency and catwalks code that had to be done to get all of this to work properly.
You no longer have to be afraid of falling off of glass floors, catwalks, or transparent tiles. Also lighting overlays don't glitch through upper z-levels anymore for transparent tiles.
Implements the Modernizing radiation design document ( https://hackmd.io/@tgstation/rJNIyeBHt ) and replaces the current radiation sources with the new system, as well as replacing/removing a bunch of old consumers of radiation that either had no reason to exist, or could be replaced by something else.
Diverges from the doc in that items radiation don't go up like explained. I was going to, but items get irradiated so easily that it just feels pretty lame. Items still get irradiated, but it's mostly just so that radiation sources look cooler (wow, lots of stuff around going green), and for things like the geiger counter.
Instead of the complicated radiation_wave system, radiation now just checks everything between the radiation source and the potential target, losing power along the way based on the radiation insulation of whats in between. If this reaches too low a point (specified by radiation_pulse consumers), then the radiation will not pass. Otherwise, will roll a chance to irradiate. Uranium structures allow a delay before irradiating, so stay away!
thanks to putnam for reporting this in coderbus
/obj/machinery/smartfridge/drying_rack/load(/obj/item/dried_object)
looks pretty harmless right? youd think that this would make a proc argument called dried_object of type /obj/item but no, this defines a new /obj/item class definition called dried_object with zero changes from /obj/item
you can use this to do weird things, like /obj/machinery/smartfridge/drying_rack/load(/obj/item/var/dried_object = 3)
creates a new var on /obj/item called dried_object and is very cursed
gets rid of 4 of these abominations, they dont seem to have caused any bugs except for maybe behavior that relies on typesof(/some/path)
Meat steaks now have the material flag to un-link from from material effects, meaning that monkey meat will now have the proper nutrients and reagents it was intended to, primarily that monkey meat will have protein for cytology purposes.
(Basically, the meat mat was not adding a food component, but then trying to remove "any" food component regardless of a material_no_effects flag. Kinda a mess, and maybe this could be done in an event based way, but this is a real sane fix. The hard part was tracking down the error anyway. Kudos fictional arcane who will read this commit message)
* Implements a combustible_flooder component on plasma and hot ice. Numbers made to preserve old behaviour as much as possible for plasma. Nerfs hot ice to be in line with the original tweak PR
* Limited to only hot ice, removed traces of override temp
* Renamed gas_name into gas_id
turns out my move_stacks var doesnt work asynchronously since this bug made things with connect_loc_behalf runtime on every movement unless you somehow moved it back to the transit turf and off without it doing the runtime special.
(The sleep and hell the whole bit of code in space/Entered was unneeded, since it just happens normally as a part of move. Life is pain) -Lemon
also does misc code improvements i found while investigating ANOTHER c_l_b bug with stacks i found while testing this one, which i did NOT manage to fix unfortunately
Makes datum materials support GAGS icons without too much configuration needed. You just need to specify a base config and subtype configurations can be for specific materials. I used the cleric mace as a testing item due to it having 2 distinct regions to color, so it got migrated to this system.
Moving forward we should not be using the regular color system for datum mat items as you can get conflicts with other code adding colors whereas with this the sprite has the base colors baked in.
Also I made the gold mace shimmer, for fun.
- Adds custom materials to result of grilling
- Adds custom materials to result of atom processing
- Adds source name and job to mob_meat material if available
- Makes processed atoms have same pixel offsets as their source but randomise with each subsequent one
* Adds explosion SFX to the blastcannon and explosive compressor
- Extracts the explosion SFX and screenshake proc from the SSexplosions explosion handling proc and lets the explosive compressor and blastcannon use it.
* Miscellaneous changes
- Adds defines for the internal explosion arglist keys
- Reverses the values of the explosion severity defines
- Changes almost everything that uses `/proc/explosion` to use named arguments
- Removes a whole bunch of argname = 0 in explosion calls.
* Removes named callback arguments.
* Changes the explosion signals to just use the arguments list
Adds a simple framework to let objects respond to explosions occurring inside of them.
Changes a whole bunch of explosions to use the object being exploded as the origin of the explosion rather than the turf the object is on.
Makes the explosive compressor and blastcannon actually use the TTVs they are given.
Adds support for things responding to internal explosions.
Less snowflake code for the explosive compressor and blastcannon calculating bomb range.*
Less confusing explosion severity defines.
Less opaque explosion arguments
*does not guarantee that the solution to letting them actually use the TTV is any less snowflake.
Done using this command sed -Ei 's/(\s*\S+)\s*\t+/\1 /g' code/**/*.dm
We have countless examples in the codebase with this style gone wrong, and defines and such being on hideously different levels of indentation. Fixing this to keep the alignment involves tainting the blames of code your PR doesn't need to be touching at all. And ultimately, it's hideous.
There are some files that this sed makes uglier. I can fix these when they are pointed out, but I believe this is ultimately for the greater good of readability. I'm more concerned with if any strings relied on this.
Hi codeowners!
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
Adds in the proper flag to Titanium, Plastic, Adamantine, Wood and Mythril in order for them to actually be able to be put in an autolathe. These are the materials that used to be missing that flag but were meant for autolathe usage.
* Bespoke Material Backend
- Adds support for bespoke materials:
- Reimplements [/datum/material/var/id]
- Ports GetIdFromArguments from SSdcs
- Adds a wrapper define for GetMaterialRef
- Adds [MATERIAL_INIT_BESPOKE]
- Adds [/datum/material/proc/Initialize]
- Does not actually add any bespoke materials
- [ ] TODO: Code docs
- [ ] TODO: Actually adding bespoke materials
* Some has_material procs and cleaning up some spaghetti
- Adds a pair of has_material procs for use in checking whether a given atom has a given material
* Adds meat
- Adds bespoke meat variants
- Does not make them accessible
- Shuts up the linter
* Implements bespoke meat
- Makes the material container preserve bespoke materials
- Makes the sheetifier accept bespoke materials
- Makes the autolathe accept bespoke materials
- Makes the gibber produce bespoke meats
* Makes butchering produce bespoke meats
This is jank and really needs to be folded into a unified butchering and gibbing system
* Material documentation
- Adds, fixes, and touches up some documentation
* Material container insertion callback
- Changes the proc used to expand the material container's material list ot a proc used to check whether a material fits into a material container
- Instantiating new materials is no longer O(n) relative to the number of autolathes in existence.
* Makes processing meat conserve materials
- Makes bespoke meat carry over into meatballs
* Makes preserving custom materials an option
- Implements the ability to turn preserving custom materials _off_ for processor recipes
* Fixes all bespoke materials of the same type using the same singleton
- We use ids now, not just types.
* Makes the fat sucker produce bespoke meats
- Because consistency is good.
* Fixes autolathes merging bespoke stacks into normal stacks.
* Makes the callback to test materials for holdibility optional
- @Floyd
* GetMaterialRef -> GET_MATERIAL_REF
- We capitalize macros.
* Removes an extraneous callback
- Makes the sheetifier use functionality I didn't notice I implemented a few commits ago.
* Makes mob and species meat null compatible
* Fixes the ore silo
- The ore silo had really snowflake material handling that has been brought in line with the rest.
- The materials should show up in the correct order.
* Fixes minor lathe bugs
- Fixes stack_traces caused when lathes tried to fetch materials using reagent typepaths
- Fixed the selective reagent disposal topic. I have no idea how long this has been broken.
* Various documentation fixes
- Clarified a couple comments
- Removes an extraneous ?. operator
- Fixed mat floor tiles having bugged reagent temperatures
* More fixes
-/datum/material/meat/mob -> /datum/material/meat/mob_meat
- Adds atom typecheck to material containers.
* Fixes old typepaths
Fixes few statue bugs with textured materials.
Makes materials use managed filters. This can have side effects on things that already had unmanaged filters on.
Title. Changed the component backend code slightly to allow a single component to hold the total score instead of spawning new components. This should fix cases, such as material stacks without the MATERIAL_NO_EFFECTS flag, where multiple set_costum_materials calls can be made and new beauty components spawned.
imo; the ss13 audio-scape is quite barren, you can only hear most things if you can see them, which in my opinion doesn't make much sense. This changes that so you can hear further away, but falloff is much higher, so in reality you will only hear things relatively quietly when they're out of sight.
This PR increases the hearing distance of most sound by 9, excluding sounds such as antag items that are meant to be used stealthily
This PR also replaces Byond's inbuilt falloff system with something I made, (And thanks to potato for helping me throw together a formula for it). This fall-off system makes sound fall off more naturally, with sounds being full volume within a certain range, and then softly falling off until they are completely quiet. This makes for a smoother transition between "This sound is full volume" and "I dont hear this sound".
Co-authored-by: ff <ff>
Adds and implements alloy materials
Takes several materials that were mostly fluff and converts them into actual usable materials.
Messes with material code a bit to make alloys recycle back into their component materials.
Adds the alloy materials to their in-game stacks.
Materials added:
Plasteel
Plastitanium
Plasmaglass
Titaniumglass
Plastitanium Glass
Alien Alloy
Makes plasteel/plastitanium/plasmaglass and the rest able to have separate properties from their component materials. It doesn't make much sense that the materials used to seal off the supermatter chamber from the rest of the station would be prone to exploding when heated.
Allows for further expansion of materials, possibly including actual functional metallurgy and smelting at some point in the very distant future.
(Lemons note: Adds a regeneration component, used for alien alloy)
This puts food you eat in to the stomach.
If you do not have a stomach you can not eat, if you try to swallow anything you will spew it out.
Changes to surgeries:
Stomach pump can now be done on the living, and pushes out the reagents in the stomach.
Blood filter is a new tool and cleans the reagents out of the body.
This also makes it so that reagents that do not metabolize can accumulate in the stomach reducing how much food you can eat.
This PR adds the crystal invasion event, a new event involving the Supermatter and the monsters from within.
When the event starts there will be a message from centcomm announcing it, then the supermatter explode leaving a destabilized crystal that emits radiations and harmful gases; after a bit portals will spawn around the station, that will produce a number of monsters each. there are 4 types of waves and 4 types of portals
The waves are: Small, Medium, Big, Huge (each have different kind of portals that can spawn and different amounts too)
The portals are the same types of the waves, they differ from each other for the number of monsters that can spawn and the kind of monsters that can spawn (bigger portals spawn stronger monsters)
To end the event the players should stabilize the crystal by destroying the portals (for now are indestructible and they are disabled by using an anomaly neutralizer, might change that) and collecting otherworld crystals; then those crystals are to be put in the crystal stabilizer, an item unlockable in the tech tree. After this just inject the destabilized crystal with it and the remaining portals will close on their own (the spawned monsters will still remain tho so you have to slay them)
All the numbers are mostly eyeballed and could change if requested/with feedbacks
