First issue: Certain crafting recipes (for example, Hooch) require a bottle, 100u hooch and a paper bag. If the 100u of hooch is in the bottle, because the crafting recipe has the bottle before the hooch in the requirements list, the craft will runtime as the bottle is "consumed" along with all its reagents.
To remedy this, I've created a simple sorter proc that runs when the global recipe list is inited. Before each recipe is added to the global recipe list, it now sorts the crafting requirements so that reagents are always processed first.
It's not exactly pretty, but it solves having to either refactor crafting code (please God no) or to go through every recipe datum and manually reorder the req list or create a unit test to ensure all recipe reqs are in the appropriate order.
Second issue: When crafting consumes a container, it qdels it and thus qdels all the items inside of it.
I've added two snowflake checks to empty the contents of reagent_containers and storage items before they are qdel'd. No more accidentally deleting items through crafting.
Loosely adapted from /vg/. This is an entity component system for adding behaviours to datums when inheritance doesn't quite cut it. By using signals and events instead of direct inheritance, you can inject behaviours without hacky overloads. It requires a different method of thinking, but is not hard to use correctly. If a behaviour can have application across more than one thing. Make it generic, make it a component. Atom/mob/obj event? Give it a signal, and forward it's arguments with a SendSignal() call. Now every component that want's to can also know about this happening.
See this thread for an introduction to the system as a whole.
Timberpoes
60ee1c4a22