## 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
The recipes are locked behind a particular skillchip anyway. We might as
well just use the framework for learnable recipes instead of relying on
a particular trait with no other use to it. This also prevents these
recipes from showing in the menu even if the requirements aren't met.
## Why It's Good For The Game
See above.
## Changelog
🆑
refactor: Underwater basketweaving refactored so it doesn't show in the
crafting menu unless you've the skillchip active.
/🆑
## About The Pull Request
The PR everyone has been waiting for...fixed toilet bong crafting. Now
you can craft them just as before using the new crafting system.
In attempting to fix this I encountered one of the gnarliest, nastiest,
meanest and most infuriatingly difficult to debug bugs I have come
across so far. And it's existed for as long as the crafting system has,
but due to unique circumstances it has been allowed to go unnoticed this
whole time.
Technical details below. Full list of changes here:
- crafting recipes can now contain structures as part of their
requirements
- removed deprecated var 'additional_req_tex' and changed text to use
the 'steps' list instead so they actually show in the gui
- toilet bongs are now passable terrain like normal toilets are
- fixed an atrocious bug with crafting that was by pure coincidence not
causing any problems
- this bug would prevent any recipes that did not contain a material
from deleting properly
- this bug would also cause any recipes that are supposed to use but not
consume machinery to consume them regardless
---
Basically, the bug that took me hours upon hours of debugging and
head-scratching to find is this:
from crafting.dm:
```
main_loop:
for(var/path_key in requirements)
amt = R.reqs[path_key] || R.machinery[path_key]
if(!amt)//since machinery can have 0 aka CRAFTING_MACHINERY_USE - i.e. use it, don't consume it!
continue main_loop
```
specifically this line:
`amt = R.reqs[path_key] || R.machinery[path_key] `
The culprit ended up being that if you do machinery[path_key] on an
empty list, it can lead to very unexpected behavior (see: EXITING THE
FUNCTION without actually doing anything).
I spent so much time thinking that item deletion wasn't working because
amt was being set to 0, false, or null perhaps when no, it wasn't that.
The function was just exiting out even before the (!amt) check due to
the atrocities committed by someone before me.
Setting amt = `R.reqs[path_key] || R.machinery[path_key]` on the other
hand always evaluates to a positive integer (either the successfully
retrieved reqs amt, or a 1 from the OR expression). It was only by
coincidence that the code did what it was supposed to, because:
1) Every single recipe has R_reqs, so the first part will never cause
the function-exiting failure because the list is never empty.
2) As for the second part of the expression, there are no recipes that
make use of CRAFTING_MACHINERY_USE, so the fact that machinery[path_key]
was never actually being accessed and thus set to a var (which is what
causes the function to exit) didn't matter.
So these two things together have basically allowed a really bad bug to
go unnoticed this whole time. I only noticed it because when trying to
add a third part to the expression it just did not work at all how you
would expect.
The solution is rather simply to add a check like so:
```
main_loop:
for(var/path_key in requirements)
amt = R.reqs?[path_key] || R.machinery?[path_key]
if(!amt)//since machinery can have 0 aka CRAFTING_MACHINERY_USE - i.e. use it, don't consume it!
continue main_loop
```
Fixes https://github.com/Skyrat-SS13/Skyrat-tg/issues/18732 .
## Why It's Good For The Game
Fixes a bug with crafting that would inevitably torment someone else as
soon as they tried to add the right kind of recipe, if that hasn't
already happened by now.
<details>
<summary>Toilet bongs are back baby!!</summary>
</details>
## Changelog
🆑
fix: toilet bongs crafting recipes
fix: fixed crafting itself
refactor: cleaned up some old code in the recipes file, added support
for structures in recipes
/🆑
## About The Pull Request
Breaking down #72371 because it's... unreasonably large.
So this PR splits the crafting recipe file, and adds 3 new recipes for
fireaxe cabinets, mech removal cabinets, and mirrors.
## Why It's Good For The Game
Wallening compliance, and more of me on my shit breaking down long
files.
## Changelog
🆑 Tattle
qol: fireaxe cabinets, mech removal cabinets, and mirrors can now all be
crafted
/🆑
Co-authored-by: tattle <article.disaster@gmail.com>
Ghom
