Files
Bubberstation/code/datums/components
MrMelbert ecde5633bd Refactors bar drink icons into datum singletons / unit tests them (#71810)
## About The Pull Request

- Refactors bar drink icons.
- Juice boxes no longer have a hard-coded list of a bunch of reagent
types in their update state, and use a system similar to bar drinks.
- Glass and shot glass icon information are no longer stored on the
drink. Instead, they are now stored in glass style datums. These datums
store name, description, icon, and icon state of a certain container +
reagent type.
- Glass styles are applied via the `takes_reagent_appearance` component.
Glasses, shot glasses, and juice boxes have this component.
- This comes with support for being able to have drink icons from
different files, rather than requiring the drinks DMI.
- The britmug is now a subtype of mug. 
   -  1 new icon: britmug filled.
- Various small code clean-up around drink reagents. 
- Unit tests icon state setups for glass styles as well as all `/drink`
reagent container subtypes.
- Splits up the massive `drinks.dmi` into separate files. 

*Disclaimer: Much of the drinking glass datums were written via script
automatically, so there may be errors present.*

## Why It's Good For The Game

- Much easier to add new drink styles, much more modular. 
- It is no longer necessary for new drinks to be added to the massive
`drinks.dmi`. People working with drinks in the future can simply add
their glass style datum and point it to their file wherever it may be.
- Expandable system. Adding a new type of reagent container that works
similarly to bar drinks but for different types of icons is a breeze.
- Ensures going forward no bar drinks have invisible sprites. 

## Changelog

🆑 Melbert
refactor: Refactored how bar drinks set their icons. Juice boxes now use
the same system.
/🆑
2022-12-14 15:23:01 +13:00
..
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-12-08 10:20:57 +13:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-12-08 10:20:57 +13:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-12-08 10:20:57 +13:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-29 20:13:28 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-12-08 10:20:57 +13:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-12-08 10:20:57 +13:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00

Datum Component System (DCS)

Concept

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.

HackMD page for an introduction to the system as a whole.

See/Define signals and their arguments in __DEFINES\components.dm