## About The Pull Request
Extends the part of the crafting unit test that ensures consistency
between the total mats of the components of a recipe (or rather, the
result of said recipe) and a generic instance of the same type as its
result, previously only implemented on food recipes.
## Why It's Good For The Game
This ensures a degree of consistency with the material composition of
various objects in the game. I couldn't do it in the original PR as that
one was too big already and it took months to get it merged, and have
the relative bugs fixed.
Currently a WIP as I slowly deal with the unit test reports.
## Changelog
🆑
refactor: Follow-up to the crafting/material refactor from months ago.
All objects crafted with stacks now inherit their mat composition (not
necessarily the effects and color) by default, while previously only a
few things like chair, sinks and toilets did. Report any object looking
or behaving weirdly as a result.
fix: The material composition of ammo boxes is no longer a 1/10 of what
it's supposed to be. It was a shitty hack to make it harder to recycle
empty ammo boxes. Instead, they lose materials as they're emptied now.
/🆑
## About The Pull Request
In https://github.com/tgstation/tgstation/pull/92884, someone pointed
out that logs from tree flora only yielded **one** plank when cut, which
isn't enough to make a bonfire, and also is ridiculously low.
This PR ups that amount from 1 to 10, just enough to craft a bonfire.
I'd also make tree chopping not so instantaneous and slightly more
realistic, however that's outside the scope of this PR.
## Why It's Good For The Game
Trees are weak af source of wood compared to hydroponics.
## Changelog
🆑
balance: Tree logs (not hydroponics towercaps) give more planks when
cut. From 1 -> 10.
/🆑
## 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
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
<img alt="0Jva48mReD"
src="https://github.com/user-attachments/assets/8b5ef2a2-c1dd-4561-89ef-15c0ca199e5d">
Renamed all seed packs to say "Apple seed pack" instead of "Pack of
apple seeds.
## Why It's Good For The Game
Shorter and better for UIs.
Easier to find the needed items in a list, the important part of the
name won't be truncated by ellipsis.
## Changelog
🆑
qol: Renamed seed packs to have the plant name at the beginning
/🆑
## About The Pull Request
Anyone that's ever played botany knows that cutting down tower cap logs
simply nukes your chat, it used to spam it with ***three*** messages for
each log that's been turned into planks.
*Not anymore!*
Now, it simply shows you a balloon alert to inform you of how many
planks you've created. Not only that, but it also cleans up the code
that was being used there, instead letting the stacks attempt to merge
on their own, rather than having their own implementation, which is what
led to cotton bundles to cause runtimes from trying to merge things
manually after accidentally having the spawned raw cotton being merged
automatically.
It also has the benefit of no longer causing the final stack of items to
move all over the place every time you cut a log, instead it stays in
place until it's full, and *only then* does a new one appear at a random
position on the tile, making it a lot less annoying when cutting logs
whilst standing on the same tile as them.
## Why It's Good For The Game
Less chat spam is *always* good. You don't *need* a live update to the
count of planks in your plank stack, you can just shift-click it to
examine it to know. Much, much neater that way.
## Changelog
🆑 GoldenAlpharex
qol: Grown logs no longer spam your chat when cut into planks, instead
displaying balloon alerts informing you of how many planks were made!
qol: Cotton and Durathread bundles no longer spam your chat either, and
display a balloon alert instead.
fix: Cotton and Durathread bundles no longer runtime when creating raw
cotton/durathread from the created stack having been merged with an
existing one.
/🆑
## About The Pull Request
FOV as it is currently implemented is incompatible* with wallening.
I'm doin wallening, so we gotta redo things here.
The issue is the masking of mobs. Wallening relies on sidemap (layering
based off physical position), which only works on things on the same
plane (because planes are basically sheets we render down onto)
So rather then masking mobs, let's reuse the masking idea from old fov,
and use it to cut out a bit of the game render plane, and
blur/over-saturate the bit that's masked out.
My hope is this makes things visible in light, but not as much in
darkness, alongside making more vivid shit more easily seen (just like
real life)
Here's some videos, what follows after is the commits I care about
(since I had to rip a bunch of planes to nothing, so the files changed
tab might be a bit of a mess)
Oh also I had to remove the darkness pref since the darkness is doing a
lot of the heavy lifting now. I'm sorry.
Edit:
NEW FOV SPRITES! Thanks dongle your aviator glasses will guide us to a
better future.
https://github.com/tgstation/tgstation/assets/58055496/afa9eeb8-8b7b-4364-b0c0-7ac8070b5609https://github.com/tgstation/tgstation/assets/58055496/0eff040c-8bf1-47e4-a4f3-dac56fb2ccc8
## Commits I Care About
[Implements something like fov, but without the planes as layers
hell](https://github.com/tgstation/tgstation/commit/a604c7b1c8d74cd27af4d806d85892c1f7e35ba8)
Rather then masking out mobs standing behind us, we use a combo color
matrix and blur filter to make the stuff covered by fov harder to see.
We achive this by splitting the game plane into two, masking both by fov
(one normally and one inversely), and then applying effects to one of
the two.
I want to make the fov fullscreens more gradient, but as an effect this
is a good start
[Removes WALL_PLANE_UPPER by adding a WALL_PLANE overlay to material
walls (init cost comes
here)](https://github.com/tgstation/tgstation/commit/25489337392f708cb337fbf05a2329eacdfc5346)
@Mothblocks see this. comment in commit explains further but uh, we need
to draw material walls to the light mask plane so things actually can be
seen on them, but we can't do that and also have them be big, so they
get an overlay. Sorry, slight init time bump, about 0.5 seconds. I can
kill it with wallening.
[Moves SEETHROUGH_PLANE above
ABOVE_GAME_PLANE](https://github.com/tgstation/tgstation/commit/beec4c00e01d34a04fba7c2bb98a9b70d27ead82)
I don't think it actually wants to draw here
@Time-Green I think this was you so pinging for opinion
[Resprites FOV masks to be clean (and more
consistent)](https://github.com/tgstation/tgstation/pull/80062/commits/f02ad13696b3b17658af612c62848b48609d785d)
[f02ad13](https://github.com/tgstation/tgstation/pull/80062/commits/f02ad13696b3b17658af612c62848b48609d785d)
This is 100% donglesplonge's work, he's spent a week or so going back
and forth with me sharpening these to a mirror shine, real chill
## Why It's Good For The Game
Walls are closing in
## Changelog
🆑 LemonInTheDark, Donglesplonge
image: Redoes fov "mask" sprites. They're clean, have a very pleasant
dithering effect, and look real fuckin good!
del: Changed FOV, it no longer hides mobs, instead it blurs the hidden
area, and makes it a bit darker/oversaturated
/🆑
###### * It's technically possible if we start using render targets to
create 2 sets of sources but that's insane and we aren't doing it
## About The Pull Request
Adds a fishing spot to hydroponics trays.
Chances
- 33% nothing
- 33% grass
- 20% random seed (discludes rarer seeds, such as gatfruit and most
mutations)
- 10% grass seeds
- 1% strange seed
- 1% axolotl
- 1% frog
Lightly inspired by something (I think) is possible on Goon, but
obviously entirely new code.
## Why It's Good For The Game
Mostly just for laughs, they're basins of water so surely you can get
something out of it.
## Changelog
🆑 Melbert
add: Fishers can now try their luck at fishing out of hydroponics
basins.
/🆑
## About The Pull Request
Further continous organizing and cleaning the Icons folder. There are
still some minior nitpicks left to do, but I reached my daily sanity
expenses limit again, and the faster these get in the less issues for
both me and others later. Also cleans some mess I caused by my blindness
last PR.
## Why It's Good For The Game
Saner spriters = better sprites
About The Pull Request
I've reworked multiz. This was done because our current implementation of multiz flattens planes down into just the openspace plane. This breaks any effects we attach to plane masters (including lighting), but it also totally kills the SIDE_MAP map format, which we NEED for wallening (A major 3/4ths resprite of all wall and wall adjacent things, making them more then one tile high. Without sidemap we would be unable to display things both in from of and behind objects on map. Stupid.)
This required MASSIVE changes. Both to all uses of the plane var for reasons I'll discuss later, and to a ton of different systems that interact with rendering.
I'll do my best to keep this compact, but there's only so much I can do. Sorry brother.
Core idea
OK: first thing.
vis_contents as it works now squishes the planes of everything inside it down into the plane of the vis_loc.
This is bad. But how to do better?
It's trivially easy to make copies of our existing plane masters but offset, and relay them to the bottom of the plane above. Not a problem. The issue is how to get the actual atoms on the map to "land" on them properly.
We could use FLOAT_PLANE to offset planes based off how they're being seen, in theory this would allow us to create lens for how objects are viewed.
But that's not a stable thing to do, because properly "landing" a plane on a desired plane master would require taking into account every bit of how it's being seen, would inherently break this effect.
Ok so we need to manually edit planes based off "z layer" (IE: what layer of a z stack are you on).
That's the key conceit of this pr. Implementing the plane cube, and ensuring planes are always offset properly.
Everything else is just gravy.
About the Plane Cube
Each plane master (except ones that opt out) is copied down by some constant value equal to the max absolute change between the first and the last plane.
We do this based off the max z stack size detected by SSmapping. This is also where updates come from, and where all our updating logic will live.
As mentioned, plane masters can choose to opt out of being mirrored down. In this case, anything that interacts with them assuming that they'll be offset will instead just get back the valid plane value. This works for render targets too, since I had to work them into the system as well.
Plane masters can also be temporarily hidden from the client's screen. This is done as an attempt at optimization, and applies to anything used in niche cases, or planes only used if there's a z layer below you.
About Plane Master Groups
BYOND supports having different "maps" on screen at once (IE: groups of items/turfs/etc)
Plane masters cannot cover 2 maps at once, since their location is determined by their screen_loc.
So we need to maintain a mirror of each plane for every map we have open.
This was quite messy, so I've refactored it (and maps too) to be a bit more modular.
Rather then storing a list of plane masters, we store a list of plane master group datums.
Each datum is in charge of the plane masters for its particular map, both creating them, and managing them.
Like I mentioned, I also refactored map views. Adding a new mapview is now as simple as newing a /atom/movable/screen/map_view, calling generate_view with the appropriate map id, setting things you want to display in its vis_contents, and then calling display_to on it, passing in the mob to show ourselves to.
Much better then the hardcoded pattern we used to use. So much duplicated code man.
Oh and plane master controllers, that system we have that allows for applying filters to sets of plane masters? I've made it use lookups on plane master groups now, rather then hanging references to all impacted planes. This makes logic easier, and prevents the need to manage references and update the controllers.
image
In addition, I've added a debug ui for plane masters.
It allows you to view all of your own plane masters and short descriptions of what they do, alongside tools for editing them and their relays.
It ALSO supports editing someone elses plane masters, AND it supports (in a very fragile and incomplete manner) viewing literally through someone else's eyes, including their plane masters. This is very useful, because it means you can debug "hey my X is yorked" issues yourself, on live.
In order to accomplish this I have needed to add setters for an ungodly amount of visual impacting vars. Sight flags, eye, see_invis, see_in_dark, etc.
It also comes with an info dump about the ui, and plane masters/relays in general.
Sort of on that note. I've documented everything I know that's niche/useful about our visual effects and rendering system. My hope is this will serve to bring people up to speed on what can be done more quickly, alongside making my sin here less horrible.
See https://github.com/LemonInTheDark/tgstation/blob/multiz-hell/.github/guides/VISUALS.md.
"Landing" planes
Ok so I've explained the backend, but how do we actually land planes properly?
Most of the time this is really simple. When a plane var is set, we need to provide some spokesperson for the appearance's z level. We can use this to derive their z layer, and thus what offset to use.
This is just a lot of gruntwork, but it's occasionally more complex.
Sometimes we need to cache a list of z layer -> effect, and then use that.
Also a LOT of updating on z move. So much z move shit.
Oh. and in order to make byond darkness work properly, I needed to add SEE_BLACKNESS to all sight flags.
This draws darkness to plane 0, which means I'm able to relay it around and draw it on different z layers as is possible. fun darkness ripple effects incoming someday
I also need to update mob overlays on move.
I do this by realiizing their appearances, mutating their plane, and then readding the overlay in the correct order.
The cost of this is currently 3N. I'm convinced this could be improved, but I've not got to it yet.
It can also occasionally cause overlays to corrupt. This is fixed by laying a protective ward of overlays.Copy in the sand, but that spell makes the compiler confused, so I'll have to bully lummy about fixing it at some point.
Behavior changes
We've had to give up on the already broken gateway "see through" effect. Won't work without managing gateway plane masters or something stupid. Not worth it.
So instead we display the other side as a ui element. It's worse, but not that bad.
Because vis_contents no longer flattens planes (most of the time), some uses of it now have interesting behavior.
The main thing that comes to mind is alert popups that display mobs. They can impact the lighting plane.
I don't really care, but it should be fixable, I think, given elbow grease.
Ah and I've cleaned up layers and plane defines to make them a bit easier to read/reason about, at least I think.
Why It's Good For The Game
<visual candy>
Fixes#65800Fixes#68461
Changelog
cl
refactor: Refactored... well a lot really. Map views, anything to do with planes, multiz, a shit ton of rendering stuff. Basically if you see anything off visually report it
admin: VV a mob, and hit View/Edit Planes in the dropdown to steal their view, and modify it as you like. You can do the same to yourself using the Edit/Debug Planes verb
/cl
About The Pull Request
Adds an argument to typecache generation that allows specifying the whether to include/exclude types in the input list.
Also adds another argument to specify whether to remove falsey values after the typecache is generated.
Why It's Good For The Game
Might make zaps slightly faster???
Honestly I just thought it would be a good way to condense some whitelist/blacklist typecache sets.
Runtime in stack.dm, 452: Stack merge attempted on qdeleted target stack.
it edits four lines instead of one because I removed them at first, then was too lazy to copypaste it from the code back in, and so hand typed it, and my propensity for adding spaces shone through
- This PR fixes a few botany plants mutating into themselves due to seeds inheriting the mutation list from its parent. Durathread, Jupiter Cups, Fairy Grass, Red Onions, Bamboo, Green Grapes, and World Peas (maybe some others I forgot).
- This PR also unit tests to ensure plants don't mutate into themselves.
- This PR also converts mutatelist into a proper lazylist. IT was already kinda a lazy list, in that it's null by default, but for some reason it was treated as a normal list in multiple places.
See title. Also refactors caltrops into a component because they use connect_loc_behalf which requires them to hold the state.
This also fixes COMPONENT_DUPE_SELECTIVE from just outright not working.
connect_loc_behalf doesn't make sense as an element because it tries to hold states. There is also no way to maintain current behaviour and not have the states that it needs.
Due to the fact that it tries to hold states, it means the code itself is a lot more buggy because it's a lot harder to successfully manage these states without runtimes or bugs.
On metastation, there is only 2519 connect_loc_behalf components at roundstart. MrStonedOne has told me that datums take up this much space:
image
If we do the (oversimplified) math, there are only ever 5 variables that'll likely be changed on most connect_loc_behalf components at runtime:
connections,
tracked,
signal_atom,
parent,
signal_procs
This means that on metastation at roundstart, we take up this amount: (24 + 16 * 5) * 2519 = 261.97600 kilobytes
This is not really significant and the benefits of moving this to a component greatly outweighs the memory cost.
(Basically the memory cost is outweighed by the maint cost of tracking down issues with the thing. It's too buggy to be viable longterm basically)
* Makes turfs persist signals
* Splits connect_loc up into two elements, one for stuff that wishes to connect on behalf of something, and one for stuff that just wants to connect normally. Connecting on behalf of someone has a significant amount of overhead, so let's do this to keep things clear
* Converts all uses of connect_loc over to the new patterns
* Adds some comments, actually makes turfs persist signals
* There's no need to detach connect loc anymore, since all it does is unregister signals. Unregisters a signal from formorly decal'd turfs, and makes the changeturf signal persistance stuff actually work
* bro fuck documentation
* Changes from a var to a proc, prevents admemems and idiots
* Extra detail on why we do the copy post qdel
Converts most spans into span procs. Mostly used regex for this and sorted out any compile time errors afterwards so there could be some bugs.
Was initially going to do defines, but ninja said to make it into a proc, and if there's any overhead, they can easily be changed to defines.
Makes it easier to control the formatting and prevents typos when creating spans as it'll runtime if you misspell instead of silently failing.
Reduces the code you need to write when writing spans, as you don't need to close the span as that's automatically handled by the proc.
(Note from Lemon: This should be converted to defines once we update the minimum version to 514. Didn't do it now because byond pain and such)
Converts many proc overrides to properly use list/modifiers, fixes some spots where modifiers should have been passed, calls modifiers what it is, a lazy list, and cleans up some improper arg names like L, M, C, and N. Oh and I think there was a spot where someone was trying to pass M.name in as a string, but forgot to wrap it in []. I fixed that too.
About The Pull Request
This PR removes intents and replaces them with a combat mode. An explanation of what this means can be found below
Major changes:
Disarm and Grab intents have been removed.
Harm/Help is now combat mode, toggled by F or 4 by default
The context/verb/popup menu now only works when you do shift+right-click
Right click is now disarm, both in and out of combat mode.
Grabbing is now on ctrl-click.
If you're in combat mode, and are currently grabbing/pulling someone, and ctrl-click somewhere else, it will not release the grab (To prevent misclicks)
Minor interaction changes:
Right click to dissasemble tables, racks, filing cabinets (When holding the right tool to do so)
Left click to stunbaton, right click to harmbaton
Right click to tip cows
Right click to malpractice surgery
Right click to hold people at gunpoint (if youre holding a gun)
Why It's Good For The Game
Intents heavily cripple both the code and the UI design of interactions. While I understand that a lot of people will dislike this PR as they are used to intents, they are one of our weakest links in terms of explaining to players how to do specific things, and require a lot more keypresses to do compared to this.
As an example, martial arts can now be done without having to juggle 1 2 3 and 4 to switch intents quickly.
As some of you who saw the first combat mode PR, the context menu used to be disabled in combat mode. In this version it is instead on shift-right click ensuring that you can always use it in the same way.
In this version, combat mode also no longer prevents you from attacking with items when you would so before, as this was something that was commonly complained about.
The full intention of this shift in control scheme is that right click will become "secondary interaction" for items, which prevents some of the awkward juggling we have now with item modes etcetera.
Changelog
cl Qustinnus
add: Intents have been replaced with a combat mode. For more info find the PR here: #56601
/cl
Refactors the nearly completely stateless component "caltrop" into an
element. The previous limit on "one message per caltrop per second" has
been changed to "one message (about caltrops) per mob per second".
This avoids a unique component for each shard of glass, and each cactus
in the world, so saves some much needed memory.
A message about "sliding over" caltrops has been removed, since it's
now intended that you only trigger caltrops if you're not lying down.
* HARK! THERE ARE SOME MAIDENS THAT NEED SAVING!
* claymores, chairs
* mapmerge, price increase, no losing the flag, no teleporting in, other small stuff
* oldworld language, medieval mutation, reviews
* see desc for full changelog
huge improvements to how medieval speech feels, CTF now fully lit, json beautified, bugs squashed and more NOTELEPORT exploits also quashed. (I NEED TO UNDO THIS FOR ATOMIZATION)
* removes my fixes? also bugfixes and CTF separation
* dumb json mistake, starting work on reality simulators
* BOWS ARE BROOOOOOOOOOOOOOOOOKEN
* br
* getting closer to working
* well, mostly everything now.
* finally ready
* removes languages stuff as it is buggy and does not work, fixes more bugs, fixes more bugs, fixes more bugs
* conflict fix
* linting
* more lint
* bow buff, speech fix, TON of ctf fixes
* oh fuck year
* NO MORE INSTA DELETING CREW
* whoops
* review handled
* pooosh
* conflict fix
Yeah uhh this'll probably need testmerging even after it's done because yeah it's a bit big.
If y'all want me to atomize this into two PRs (pass flags vs projectiles) tell me please. Pass flags would have to go in first though, in that case, as new projectile hit handling will rely on pass_flags_self.
Pass flags:
Pass flags handling now uses an atom variable named pass_flags_self.
If any of these match a pass_flag on a thing trying to pass through, it's allowed through by default.
This makes overriding CanAllowThrough unnecessary for the majority of things. I've however not removed overrides for very.. weird cases, like plastic flaps which uses a prob(60) for letting PASSGLASS things through for god knows why.
LETPASSTHROW is now on pass_flags_self
Projectiles:
Not finalized yet, need to do something to make the system I have in mind have less unneeded overhead + snowflake
Basically, for piercing/phasing/otherwise projectiles that go through things instead of hitting the first dense object, I have them use pass_flags flags for two new variables, projectile_phasing and projectile_piercing. Anything with pass_flags_self in the former gets phased through entirely. Anything in the latter gets hit, and the projectile then goes through. on_hit will also register a piercing hit vs a normal hit (so things like missiles can only explode on a normal hit or otherwise, instead of exploding multiple times. Not needed as missiles qdel(src) right now but it's nice to have for the future).
I still need to decide what to do for hit handling proper, as Bump() is still preferred due to it not being as high-overhead as something like scanning on Moved(). I'm thinking I'll make Moved() only scan for cases where it needs to hit a non-dense object - a prone human the user clicked on, anything special like that. Don't know the exact specifics yet, which is why this is still WIP.
Projectiles now use check_pierce() to determine if it goes through something and hits it, doesn't hit it, or doesn't go through something at all (should delete self after hitting). Will likely make an on_pierce proc to be called post-piercing something so you can have !fun! things like projectiles that go down in damage after piercing something. This will likely deprecate the process_hit proc, or at least make it less awful.
scan_for_hit() is now used to attempt to hit something and will return whether the projectile got deleted or not. It will delete the projectile if the projectile does hit something and fails to pierce through it.
scan_moved_turf() (WIP) will be used for handling moving onto a turf.
permutated has been renamed to impacted. Ricocheting projectiles get it reset, allowing projectiles to pierce and potentially hit something again if it goes back around.
A new unit test has been added checking for projectiles with movement type of PHASING. This is because PHASING completely causes projectiles to break down as projectiles mainly sense collisions through Bump. The small boost in performance from using PHASING instead of having all pass flags active/overriding check_pierce is in my opinion not worth the extra snowflake in scan_moved_turf() I'd have to do to deal with having to check for hits manually rather than Bump()ing things.
Movement types
UNSTOPPABLE renamed to PHASING to better describe what it is, going through and crossing everything but not actually bumping.
Why It's Good For The Game
Better pass flags handling allows for less proc overrides, bitflag checks are far less expensive in general.
Fixes penetrating projectiles like sniper penetrators
This system also allows for better handling of piercing projectiles (see above) without too much snowflake code, as you'd only need to modify on_pierce() if you needed to do special handling like dampening damage per target pierced, and otherwise you could just use the standardized system and just set pass flags to what's needed. If you really need a projectile that pierces almost everything, override check_pierce(), which is still going to be easier than what was done before (even with snowflake handling of UNSTOPPABLE flag process_hit() was extremely ugly, now we don't rely on movement types at all.)
* Process procs now properly use deltatime when implementing rates, timers and probabilities
* Review fixes
* Geiger counters cleanup
Made hardsuit geiger code more similar to geiger counter code
Geiger counters are more responsive now
* Moved SS*_DT defines to subsystems.dm
* Rebase fix
* Redefined the SS*_DT defines to use the subsystem wait vars
* Implemented suggested changes by @AnturK
* Commented /datum/proc/process about the deltatime stuff
* Send delta_time as a process parameter instead of the defines
Also DTfied acid_processing
* Dtfied new acid component
Shoutout to skog for helping me fine tune a lot of the ideas for this as well as convincing me to do it anyway. Feel free to send me your adoration and glory (once this is actually balanced and tested out so I can work out the like 1000 little runtimes and bugs this will surely have.)
About The Pull Request
Lets Start with everything that DIDN'T change.
Plants still have all their unique qualities. That includes chems, traits, all that good stuff.
Plant stats have been unchanged, with an exception I'll bring up later.
Cool. Onto everything else.
Changes to hydroponics trays.
Trays now have a new feature that visually you may be very familiar with. By Ctrl Clicking a tray, it activates Autogrow. Autogrow uses a HEAVY amount of power per tray, but in return it automatically maintains the plant contained within, limited nutrient loss, adding a gradual amount of water per process, and keeps pests and weeds at bay. Ideally you would only be using this on high maintenance plants, or if you need to leave your department for a few minutes. Having all your trays on Autogrow is an excellent way to kill your APC cell in a matter of seconds, even on a robust power setup.
Trays no longer use **Nutrient Points.** Instead, each tray has an internal reagent holder that basically holds a beaker for your plant's nutrients. In exchange, the tray now determines the gradual stat changes of plants based on nutrients within that nutrient tank. That's right, no more dumping chemicals into the tray to reach 100 potency in a matter of minutes. You can, however, use reagent mixes in order to improve plant stats in a satisfying way. Still, with each tray having a default of 10 reagents maximum in the tank, it places a greater impetus on upgrading trays if want to really get the most of a specific chemical composition.
If you realize you need to change the nutrients in the tank, you can Alt Click to empty the whole tank at once.
Seed Changes
All plants now have a new stat, Instability. (It was originally titled stability so I'm changing it here but yes it is now called instability) Contrary to the name, the higher the stability of the plant, the more likely that your plant will see radical changes. Plants with a low stability will not see much difference, but as you go higher and higher you will start seeing the plant automatically mutate with harsher ramifications. At 60 Stability, the plant has a chance to automatically mutate it's species. At 80 Stability, assuming you can prevent the plant from mutating beforehand, the plant has a chance to receive random plant traits similar to strange seeds. That's right! You can now be free from the tyranny of the strange seed market!
Plants are now affected differently by pests and weeds. Instead of outright killing plants, they will instead heavily lower a plant's yield and potency instead. This also allows for plants that have been left for a few minutes to outright die far less than they were before, but at the same time encourage using autogrow when AFK within the department.
When growing a plant however, you have something new to consider. Plants will now pollinate adjacent seeds in trays, which will bleed off adjacent stats to other plants. Primarily, this affects your core stats. like potency, yield, also stability. If you have 2 plant with high and low potency, they'll bleed their stats off into each other as they grow. This allows for interesting mechanical gameplay between nutrient choices, stability, and adjacency. Some plants have naturally high stability that can bleed off of other plants (Corn, Wheat, and Weeds), while others have naturally low stability and can help bring plants back into a maintainable stability threshold if you just want to harvest the plant itself.
Pollination at high levels of stability can also cause the adjacent plants to receive chemical traits from each other. This allows for plants to share chemical traits without having an insane level of control afforded by the DNA manipulator. However, careful manipulation of plant reagents is difficult to do perfectly, and should be done carefully, as well as experimentally.
For a more controlled trait experience however, we have Plant Grafts. Plant grafts are obtained by using the new secateurs, or sheers, that comes with the botanist's default kit. When a plant is ready to harvest, you can cut off a plant graft, which carries several of the plant's stats and qualities with it. When transplanted, you can share the unique traits of several plants into a new host. These traits are mostly the physical traits you're most likely familiar with, like bio-luminescence, slippery skin, liquid contents, the works. You can also store plant grafts if there's a specific trait build you'd like to eventually get to. Since you need to fully grow a plant to graft it, the process of obtaining several unique traits for a plant will result in more types of plants needing to be grown as a result.
Alright, this leads up to what you're probably guessing. DNA manipulator for plants is dead. Even if it's really good, being able to Frankenstein a dozen different plants together without even growing half of them is kinda lame, you have to admit. The new trait and chemical controls are a bit more robust overall to compensate for this.
image
Why It's Good For The Game
Chemical dependence hydroponics is dead.
Genefreak maxed out stats plants are dead.
The Tyranny of Pests and Weeds killing plants for cooperating with the station is dead.
Ambrosia Gaia is now no longer the staple plant of hydroponics, as earthblood trays are dead.
Plant mutations are now easier to come by, and can be achieved within 2 plant generations assuming you're not crossbreeding and using readily available chems.
Chefs, and by extension bartenders, get a wider array of plant's each to work with.
Botanists are no longer required to acquire a chem dispenser at shift-start to acquire mutated plants.
Crosspollination, mutation, and grafting allows for a more interesting dynamic in improving plant stats, as opposed to just clicking buttons. It also rewards planning and developing system for growing plants.
Changelog
🆑
add: Plants can now Cross-Pollinate, via adjacency. This causes plant stats of average into each-other.
add: Plants now have a new stat, Instability. Instability allows for gradual mutations to a plant's stats at certain thresholds, and a chance of mutation, or gaining new random traits at even higher thresholds.
add: Plants can be grafted when ready to harvest, and grafts can be applied to plants in order to share unique traits, or share stat changes.
del: The Plant DNA Manipulator is dead. Long Live the DNA manipulator.
tweak: Hydroponics trays now have their own internal beaker for holding chemical reagents. As such, chemical affects on plants are gradual, and slowly alter seed stats over generations.
balance: Several chemicals are adjusted to match the new system. Experiment!
/🆑
* Makes all CanPass procs call parent
* Makes CanPass more extendable and gives the mover a say in the matter
* Replace CanPass with CanAllowThrough to use the new system
Regex replace `(?<!proc)/CanPass\(` => `/CanAllowThrough(`
* Simple optimization pass
* Doubtful improvement
* Switches out all the magic numbers with defines
* Thanks travis for finally finding a real error
* properly resolves some left over conflict
* Reverts italics-span back to no color.
* Cleans up many extra spaces and indents.
* Adds 'hear' span class.
* Replaces all 'italics' used in heard messages with 'hear'.
This makes lavaland atmos random per round. You won't get eternally burning hell worlds or vacuums but it's nice for a bit of variety.
Admins can edit the gas mixture for all of lavaland at once if they want to ruin some miners' day.
image
cl
add: Lavaland atmos is no longer a preset gas mixture and varies per round
tweak: Bonfire minimum oxygen content has been reduced
/cl
