## About The Pull Request
Not really sure why these were there storing the lists in memory
permanently, when these just get consumed anyway. People copy paste them
all over it seems so I'm going to put a stop to that.
## Why It's Good For The Game
Cleans up like 7 years of cargo cult.
## Changelog
Not player-facing
## About The Pull Request
Reverts the storage initialization refactor and all subsequent related
PRs.
The original PR is below our standards both for code quality and
testing, and is majorly flawed at its core. This has been discussed with
other maintainers and headcoder(s?) over on discord. A lot of changes
from the PR could be brought over later, but in its current state it
should not have been merged.
- Closes#90322
- Closes#90313
- Closes#90315
- Closes#90320
- Closes#90312
- Closes#90344
## Why It's Good For The Game
This PR causes a series of major issues which cannot be resolved without
either completely rewriting a lot of the original PR, or bad code.
Not matching our standards is grounds for not merging a PR, and the fact
that a PR should not have been merged is a reason for a revert.
## Changelog
🆑
fix: Fixed a series of storage-related bugs caused by a refactor PR.
/🆑
## About The Pull Request
A Huge chunk of changes just comes from moving existing storage code
into new files & seperating `atom_storage` code into its own subtype
under the already existing `storage/subtypes` folder.
With that the changes in this PR can be organized into 3 categories.
**1. Refactors how `/obj/item/storage/PopulateContents()` initializes
storages**
- Fixes#88747 and every other storage item that has a similar variant
of this problem
The problem with `PopulateContents()` is that it allows you to create
atoms directly inside the storage via `new(src)` thus bypassing all the
access restrictions enforced by `/datum/storage/can_insert()` resulting
in storages holding stuff they shouldn't be able to hold.
Now how this proc works has been changed. It must now only return a list
of items(each item in the list can either be a typepath or a solid atom
or a mix of them in any order) that should be inserted into the storage.
Each item is then passed into `can_insert()` to check if it can fit in
the storage.
If your list contains solid atoms they must be first moved
to/Initialized in nullspace so `can_insert()` won't count it as already
inserted. `can_insert()` has now also been refactored to throw stack
traces but explaining exactly why the item could not fit in the storage
thus giving you more debugging details to fix your stuff.
A large majority of changes is refactoring `PopulateContents()` to
return a list instead of simply creating the item in place so simple 1
line changes & with that we have fixed all broken storages(medical
toolbox. electrical toolbox, cruisader armor boxes & many more) that
hold more items they can handle
**2. Organizes initialization of `atom_storage` for storage subtypes.**
All subtypes of `/obj/item/storage` should(not enforced) create their
own `/datum/storage/` subtype under the folder `storage/subtypes` if the
default values are not sufficient. This is the 2nd change done across
all existing storages
Not only does this bring code cleanliness & organization (separating
storage code from item code like how `/datum/wire` code is separated
into its own sub folder) but it also makes storage initialization
slightly faster (because you are not modifying default values after
`atom_storage` is initialized but you are directly setting the default
value in place).
You now cannot & should not modify `atom_storage` values inside
`PopulateContents()`. This will make that proc as pure as possible so
less side effects. Of course this principle is not enforced and you can
still modify the storage value after `Initialize()` but this should not
be encouraged in the future
**3. Adds support for automatic storage computations**
Most people don't understand how `atom_storage` values work. The comment
here clearly states that
https://github.com/tgstation/tgstation/blob/55bbfef0da70d87455ca8d6fd5c95107eb8dbefb/code/game/objects/items/storage/toolbox.dm#L327-L329
Because of that the linked issue occurs not just for medical toolbox but
for a lot of other items as well.
Which is why if you do not know what you doing, `PopulateContents()` now
comes with a new storage parameter i.e. `/datum/storage_config`
This datum allows you to compute storage values that will perfectly fit
with the initial contents of your storage. It allows you to do stuff
like computing `max_slots`, `max_item_weight`, `max_total_weight` etc
based on your storage initial contents so that all the contents can fit
perfectly leaving no space for excess.
## Changelog
🆑
fix: storages are no longer initialized with items that can't be put
back in after taking them out
refactor: storage initialization has been refactored. Please report bugs
on github
/🆑
About The Pull Request
The Export Scanner, Sales Tagger, and Price Tagger are all niche, cargo adjacent items that each perform a different minor task and if using one, requires usually one of the three extremely rarely. Each one requires printing a new item at the lathe, all for maybe one or two uses before it needs to be replaced.
This PR merges the three into a singular, modular item. Existing export scanners have been reflavored the "universal scanner". When used in-hand, it produces a radial to swap between the three modes, Each mode has identical function to their previous scanner, with the only functional difference being that the sales tagger now prints new tags on secondary attack as opposed to primary.
The other two items lathe recipes have been removed, as their functionality has been fully moved to the universal scanner.
Also flips the export scanner icon state to match the other 2 scanner items that have been lumped together.
Why It's Good For The Game
Cargo now only needs to swap between 1 of three nearly identical barcode scanner looking items at a time, as opposed to having to print an item that sees functional use once every thousand rounds. By increasing the ease of use, it will also make it easier to use custom vendors, as well as print sales tags on regular rounds, as the universal scanner can still be found in shipping boxes located around the station and in tool storages.
Arguably not a balance change, as the three tools are extremely cheap to print, and don't have a formal impact on cargo balance except for tedium.
* Preset Boxes File De-concatenation
Hey there,
We had one file that was like eighteen-hundred (1800) lines full of just... box presets. There was no rhyme or reason to where anything was in the list, it just sorta got to the point where new features were found near the bottom with zero grouping. So, let's de-concatenate this massive file and give it some proper grouping.
While I was in the area, I did some file cleanup, using `snake_case` instead of whatever the fuck some vars were, alphabetizing and cleaning up lists to have trailing commas, that sorta stuff. Let me know if I broke something somewhere.
* documentations, var improvement
* adds some documentation, clears up some variables
