Files
Bubberstation/code/datums/components
MrMelbert 08cbf579fe Fixes some shielded component jank (#79674)
## About The Pull Request

If you attempted to use the shielded component properly (applying it in
`Init`), it would not work because the equipped signal was improperly
passing its arguments to `set_wearer`.

The only reason why this worked now is that every consumer added the
component after it was `equipped`... usually in `equipped`.

This also meant shielded items that added it in equipped were open to an
exploit, allowing you to reset the charges by unequip / re-equip.

## Changelog

🆑 Melbert
fix: Fixes some potential exploits and issues involving shielded
equipment.
/🆑
2023-11-12 23:42:16 -07:00
..
2023-10-16 16:14:31 +02:00
2023-09-19 19:07:51 +00:00
2023-10-11 16:58:29 -06:00
2023-11-12 09:25:59 +00:00
2023-10-21 23:36:48 +00:00
2023-10-08 03:04:35 +01:00
2023-08-16 13:04:41 -06:00
2023-10-05 13:20:16 -06:00
2023-11-12 09:25:59 +00:00
2023-11-03 22:39:33 +00:00
2023-10-16 16:14:31 +02:00
2023-08-14 12:39:30 -06:00
2023-10-14 15:53:28 -07:00
2023-09-07 20:25:52 +01: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