## About The Pull Request
Gives duffelbags their proper slot count
They inherited this from backpacks, but I sorta just forgot about that
[Creates "levels" of locked objects, uses that to make locked duffels
work](https://github.com/tgstation/tgstation/pull/76442/commits/c613c00f62fa3ff03bb33737d24da9acbf2050e3)
[c613c00](https://github.com/tgstation/tgstation/pull/76442/commits/c613c00f62fa3ff03bb33737d24da9acbf2050e3)
Turns locked into something that holds defines, this makes life a lot
easier.
Requires a lot of boilerplate because of how many uses of these procs
there are and all the passthrough and shit.
Adds a few outfit subtypes to avoid this class of failure in future.
Renames the args in a few but not all touched procs, one thing at a time
Closes#76407Closes#76430 Had the lock check in the wrong place
Closes#76441 GOD I HATE TK SO MUCH
Wrote half the pr without glasses so if it's weird gimme some grace
yeah?
## Changelog
🆑
fix: Fixes some fuck with duffelbags, them not holding enough + issues
with spawning gear in them (job shit and all)
/🆑
## About The Pull Request
Reworks duffel bags in line with oranges proposed plan.
Basically, instead of just making you slower all the time, they make you
slower while you have them open, but give you the same speed while
they're closed.
As a trade off, opening and closing them takes time, 2.1 seconds
(matches the sound) and 0.5 respectively.
https://github.com/tgstation/tgstation/assets/58055496/555d2cd0-038e-4b0b-a693-0c66dac16f5b
[Adds support for limiting extra storage, uses it to make syndie stuff
cool](https://github.com/tgstation/tgstation/pull/76313/commits/d0b2bbf937435b36de3ba497c48771f563b76684)
[d0b2bbf](https://github.com/tgstation/tgstation/pull/76313/commits/d0b2bbf937435b36de3ba497c48771f563b76684)
Syndicate bags currently ignore downsides by just ignoring the slowdown,
but that's kinda boring so let's just buff em instead.
They now support holding a limited amount of bulky items (3), filtered
down to things that would otherwise constitute going loud (or otherwise
be useful to carry around as a loudish traitor)
I may have gone a bit overboard on what I whitelisted here, lemme know
yeah?
I also did some fenangling with backpack uses of create_storage, I don't
like this pattern it was a bad idea I think.
## Why It's Good For The Game
I'm unsure if these delays enough, I think any length of time is decent
since it means you need to stop moving and focus on it for a bit.
My hope is this will make them a proper sidegrade, rather then something
that goes unused/acts as newbie bait
## Changelog
🆑
balance: Duffelbags will now only make you slow while they are unzipped.
As a tradeoff, you now need to stand still and zip/unzip them to access
their contents/not move real slow.
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
The reusable and caseless types only purposes are the behaviors of
deleting the casing when fired and spawning a new object when the
projectile ultimately reaches its maximum range or hits a target, both
of which are easily "elementizable". Also, I don't like those barely
filled sub-folders in the projectile module, and the fact we've
divergent reusable and single use arrow types.
## About The Pull Request
Fixes#47650
Either by hand or by RPED you can now use blue space poly crystal to
finish a machine. If you are using a RPED then it will attempt to look
for singular bluespace crystals first and only if it cannot find it will
it then look for the bluespace poly crystals
Also removed some redundant types from the RPED allowed bluespace types
list cause they were not necessary
## Changelog
🆑
fix: bluespace poly crystals can be used to complete machine frames
either by hand or by RPED
/🆑
## About The Pull Request
Shoe storage can now fit box cutters, pills, and toy pistol magazines.
All of these have better-or-equal similar items that can already be
fitted in.
Box cutters - Switchblades (Better in every way)
Pills - Syringes and Medipens (Mostly sidegrades)
Toy magazines - Actual pistol magazines
## Why It's Good For The Game
More stuff you can shove into your shoes, consistency with similar
items. Honestly I'm not too fond of this strange whitelist system,
wouldn't a blacklist be better and more intuitive?
If there's any items you want me to add, comment below with them.
## Changelog
🆑
qol: Shoe storage can now fit box cutters, pills, and toy pistol
magazines.
/🆑
## About The Pull Request
Fixes: #72697
Fixes transferring cards to a binder resulting in zero card decks.
Fixes transferring cards to the floor not working at all.
## Why It's Good For The Game
Bugfixes!
## Changelog
🆑
fix: Removing cards from TGC decks by pouring them on the floor/into
binders should now function correctly.
/🆑
## About The Pull Request
I'm a bit sad about the state of trashbags.
They're very clunky to use, so they almost never get touched. S
depressing. Let's try and fix that.
Let's make em fit in the belt slot (again), but as a tradeoff we'll make
it harder to pull one thing from your bag.
We'll give it a say, 1.5 second delay, so you can't quickdraw from em.
If you try and dump them out into something else, we'll throw any
spillover on the ground below you
I'm also doing some general code cleanup here. Making procs more
readable, vars more direct, removing some old legacy stuff.
I've added a remove_single proc to hook into via subtype, which takes a
mob as input. this has required placing extra requirement on some helper
procs, but fortunately it's not something they're unable to meet.
My hope is this will make garbage bags usable without being stupid.
## Why It's Good For The Game
I don't see these get used at all, cause they're a pain to carry around.
They got gimped because people were using them as infinite storage for
shotgun shells and other small items.
I've made using them for this sort of thing hard and slow, so I think we
oughta be fine. If not I'll do some more touching, maybe give the
autodrop a delay.
## Changelog
🆑
balance: The janitor's trashbag now fits on his belt. In exchange,
taking something out of it sends a visible message, and has a delay.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
This builds on what #69790 did and improved the code even further.
Notable things:
- `Topic()` is a deprecated proc in our codebase (replaced with
Javascript tgui) so it makes sense to rename `canUseTopic` to
`can_perform_action` which is more straightforward in what it does.
- Positional and named arguments have been converted into a easier to
use `action_bitflag`
- The bitflags adds some new checks you can use like: `NEED_GRAVITY |
NEED_LITERACY | NEED_LIGHT` when you want to perform an action.
- Redundant, duplicate, or dead code has been removed.
- Fixes several runtimes where `canUseTopic` was being called without a
proper target (IV drips, gibber, food processor)
- Better documentation for the proc and bitflags with examples
## About The Pull Request
When you drag and drop a belt to another storage item it transfers all
its contents but retains its overlays. This PR calls update appearance
at the end of storage to storage transfers so this shouldn't occur
again.
## Why It's Good For The Game
Bug fix, belts appearing to have things on them which they don't is bad.
## Changelog
🆑
fix: Transferring objects from a belt to another storage object now
removes those objects from the belts visuals.
/🆑
## About The Pull Request
Right-clicking a Cigarette pack takes out a cigarette, while
Alt-Clicking takes out a lighter. If there's no lighter, then it just
takes out a cigarette instead.
## Why It's Good For The Game
Currently, if you put your lighter in the cigarette pack, then trying to
fish it out requires you to take out the packet and mill through all the
cigarettes until you get to the lighter.
This fixes that while still keeping the quick and easy functionality.
## Changelog
🆑 Wallem
qol: Smokers rejoice, you no longer need to mill through your cigarette
packet to get your lighter out. Alt-Click a cigarette packet to extract
a lighter from it, if you've put it in there. Right-Clicking will still
take out a cigarette.
/🆑
## About The Pull Request
premium internals boxes from the station trait now get 2 more slots and
have a slightly bigger sprite
also lowers the trait's weight a bit, making it equal to most other
traits.
## Why It's Good For The Game
the main reason im doing this is because this trait messes with anything
people wanna do to survival boxes, cause it takes up 2 slots, so you
have to account for that whenever youre making a subtype that you wanna
fill with more stuff, you cant really do that (currently an issue with
the nukie medical pr)
the other reason is station traits should affect the gameplay a bit more
than "wow i have 2 items i can normally get from an emergency toolbox",
a larger box doesnt change that much but its something.
## Changelog
🆑
balance: premium internals station trait now increases the slots of your
internals box
/🆑
**Note :** Rehashed & cleaned up version of PR
[#71064](https://github.com/tgstation/tgstation/pull/71064). That one
contained unrelated commits and was so bad to the point it had be
labeled with DNM. This is the clean version of it.
## About The Pull Request
Rapid part exchange device RPED & Bluespace version of it BRPED can now
A) pick up 4 types of materials
- glass sheets[max 30]
- plasteel[max 30]
- cable coil[max 30]
- Bluespace[ore,refined,artificial,stack] total sum of all these should
not exceed 30
and install them in an incomplete machine frame
B)display more verbose part information[number of parts for each type
including for stack components]
## Why It's Good For The Game
A)Some machines types such as
- [thermo
machines](https://tgstation13.org/wiki/Machines#Freezer.2FHeater)
- [electrolyzers](https://tgstation13.org/wiki/Machines#Electrolyzer)
- crystallizer=10 cable pieces , 10 glass sheets , 5 plasteel sheets
All require either cable ,glass or plasteel. Usually you have to carry
these components inside your backpack which occupy space there and later
take it out from there and install it manually by hand and then use RPED
or BRPED on the machine frame.
This feature now combines these 2 steps into 1 step thus making
installing machine frames much faster and you also saves space inside
your backpack as these are now carried inside the RPED itself
You need to insert the exact stack type capacity available inside the
RPED for it to work i.e. if you pick up 5 glass sheets then later you
need a stack of exactly 25 glass sheets to complete the stack. This is
easier from a coding perspective so we don't have to deal with
subtracting & updating appearances of the remaining stack on the ground
or the user hand.
B) When using the RPED or BRPED to display machine part information
these are the new formats
Using an RPED on an thermo machine
Using an RPED on the crystallizer
##Change Log
🆑
add: checks while inserting stack materials into an RPED and their
amounts
code: sorting of RPED part components to sort stack materials by their
ratings
del: old way of displaying parts when clicking on an machine frame with
it
add:new way of displaying part info which displays number of parts
including for stack materials
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
- Makes QDELETED use isnull(x) instead of !x, giving about 0.2 to 0.25s
of speed.
- Make disposal constructs only update icon state rather than go through
expensive overlay code. Unfortunately did not have much effect, but is
something they should've been doing nonetheless.
- Makes RegisterSignal only take signals directly as opposed to
allocating a fresh list of signals. Very few consumers actually used
this and it costs about 0.4s. Also I think this is just a bad API anyway
and that separate procs are important
`\bRegisterSignal\((.*)list\(` replaced with `RegisterSignals($1list(`
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
And removes an extra `to_chat` message for when your ore bag is full and
can't put ore in using the `silent_for_user` system.
## Why It's Good For The Game
I have been moving the chat messages that miners get bombarded every
shift away from their chat bar and into balloon alerts with the goal of
making the chat be a cleaner place for miners, as it is their only way
to interact with the station while down at lavaland.
People have been complaining that it was too much, which is fair. I've
been work on a mini rework on how ore bags function and a cleaner
feedback with ore icons falling into the bag, but I'm just not happy
with how it works now so I will restart on it.
Until I get that sorted, I added a 2 second cooldown on the balloon
alerts for picking up ore as a middle ground, it provides good feedback
for new players while not being as distracting.
## Changelog
🆑 Guillaume Prata
qol: Ore bag balloon alerts have a 2 second cooldown now and a spammy
message (hopefully the last) it send to your chat about being full was
removed
/🆑
## About The Pull Request
We have a `silent` var that makes storing/removing items from a backpack
not send a message to anyone's chat.
This adds a midway point, silent messages only for the user to cut on
spam/unnecessary messages while other players still keep them to prevent
free stealth shenanigans.
For now the only storage item I have given this new variable is the ore
bag for miners, as even with #70487 miners still have to deal with a lot
of pointless messages getting in the way of radio chatter.
## Why It's Good For The Game
Less pointless spam.
You mined the ore, you stepped on it, you get a balloon alert explaining
what happened.
There is no reason to also send the default storing/removing message to
your chat.
it can also be easily ported to other backpack/boxes/bags, I personally
would want it on basically any storage but that would hurt on new
player's feedback, so it is a conversation for another PR.
## Changelog
🆑 Guillaume Prata
qol: Ore bags are "silent" for the wearer and won't send pointless chat
messages about what has been stored/removed from it. Other players will
still get a chat message, so miners can't get away with surprise plasma
ore bombs.
/🆑
* Converts mice and rats to basic mobs
* Update paths
* Fixes
* Tweaks
* .
* Use helpers
* Unit test
* Correct the targeting
* Fixes the unit test?
* Fixes the unit test
* Docs
* update the path script with pr id
* Faction check tweak
* Review
* AHH
* Added flasks to pocket.dm shoes
Adds flasks to the valid item storage list for jackboots, clown shoes, and other similar shoes
* Added flasks to pockets.dm shoes
Adds flasks to the valid item list for storage inside jackboots, clown shoes, and similar shoes
Co-authored-by: AeronaDF <aeronadf@gmail.com>
* canUseTopic now uses TRUE/FALSE instead of defines that just say TRUE
The most idiotic thing I've seen is canUseTopic's defines, they literally just define TRUE, you can use it however you want, it doesn't matter, it just means TRUE. You can mix and match the args and it will set that arg to true, despite the name.
It's so idiotic I decided to remove it, so now I can reclaim a little bit of my sanity.
* Makes flags properly check themselves
Byond ref: https://www.byond.com/docs/ref/#/operator/&
Basically, flags should use & instead of ==
We can have more than 1 slot on any item, so it's preferred that we do this instead. Even if it doesn't immediately fix any problems, it's something that should be the standard anyways to prevent it from ever being a problem.
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
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
* - Fixes storage mass transfer
- Brings some sanity to storage procs
- Implements a griddle feature that never was
* Uncomment this
* Right-click attack fix
* Scoop fix
* Smartfridges use silent
* Restores some lost checks
* Fixes storage implants
* Makes condiments their own subtype, fixes geese, prepares for merging
* Fixes geese checking drink type instead of edible foodtype to eat gross food.
* Renames foodtype var on drinks to drink_types to prevent above from happening again because it KEEPS HAPPENING. DRINKS AREN'T FOOD!
* Makes Condiments their own subtype of reagent_containers because they don't make any use of being a subtype of food, at all.
* Starts moving things from food to /food/drink subtype in preparation for merging /food/drink with /drink
* fully removes Food subtype
* /reagent_containers/drinks are now /reagent_containers/cup - This is so it's no longer confused with eachother.
* /food/drinks is now /reagent_containers/cup/drinks, so we can keep their special abilities.
* Fixes a LOT of errors with food, which are STILL checking the reagent_containers, despite ACTUAL food being refactored away from it a long time ago.
This doesn't compile yet, but I do want to make sure my progress is well tracked.
* remove copypaste code, changes soda cans
* Removes most copy paste code between the two drinks, moving most stuff to parent whenever needed.
* Made soda cans their own subtype since they didn't share anything with glass bottles anyways.
* Fixes more problems with food/drinks, especially with geese. Geese really were just broken this whole time and no one said a word...
* Removes a snowflake signal, now that both drink types share a common one.
* Adds everything to the .dme
Currently my goal is to get this all compiling, then remove isGlass var by making glass be all glass ones only.
* Moves all icons into a single drinks dmi
I'm not that great at icon stuff, hopefully I didn't forget/break anything.
* Turns juices into their own subtype
This allows us to let them check for type in molotov, to both get rid of a use of isGlass, and so non-glass non-cartons don't show up as 'carton'.
* fixes compile issues, adds updatepaths
* a better updatepaths
* updates the damn maps now
* properly names the updatepath
* how did that get there
* i suck at handling merge conflicts
* how am i this bad
* code improvement and soda fix
* more fixes
* Don't be a timer
Ports from old food bottles to trans the reagents, rather than add a timer to.
* Merge conflicts and fixes bottle smashing
* Bottle smashing is now consistently functional regardless of how much liquid they have in them, when before it would spill first, then smash on the second hit.
* runs updatepaths again
About The Pull Request
replaces a ton of log_game with user.log_message so the log is added to individual and global logs.
adds a few logs for individual LOG_VICTIM, LOG_ATTACK etc logging.
adds logging for bluespace launchpad's tele coords being changed.
took the word "has" out of log_combat, as it's extra and just lengthens the log.
Why It's Good For The Admins
It's extremely laggy to open game.txt so an alternative is individual game logs
Changelog
cl
admin: A lot of game logs will now also be in individual game logs, for convenience in log diving.
admin: Added logging for bluespace launchpad x and y offset changes, which go to individual game logs.
admin: Attack logs will now be slightly shorter, one useless word was removed.
/cl
* On the storage datum, properly registers secondary singals to their own secondary procs to handle the different stuff they do.
* Fixes click & drag storage containers by calling them on where they are supposed to be moved to using atom_storage.
Replaces the nuke op Makarov with the Ansem, a clandestine pistol firing 10mm rounds which do more damage. Ammo costs more.
Replaces the nuke op survival knife with the energy dagger, as well as giving it a soft light, light armor penetration and a light wound bonus.
Replaces the diamond drill in their closet with an entrenching tool, which swaps between crowbar, pickaxe and shovel modes.
Gives the nuke op survival box the syndie box design, as well as a crowbar, screwdriver and mini welder.
Removes the nuke op leader's Krav Maga gloves.
Updates the esword and edagger sprites with ones i had lying around from 2019, they are more consistent.
Moves pistol sprites a bit up to center them.
Currently, storage works as a subtype of /datum/component, utilizing GetComponent() and signals to operate. While this is a pretty good idea in theory, the execution was pretty trash, and we end up with alot of GetComponent() snowflake code (something that shouldn't even need to be used frankly), and a heaping load of scattered procs that lead into one another, and procs that don't get utilized properly.
Instead, this PR adds atom_storage and proc/create_storage(. . .) to every atom, allowing for the possibility of storage on quite frankly anything. Not only does this entirely remove the need for signals, but it heavily squashes down the number of needed procs in total (removing snowflake signal procs that just lead to one another), reducing overall proc overhead and improving performance.
LemonInTheDark
