Files
Bubberstation/code/datums/components
13spacemen f9b7588bc4 bodytypes to do with body shape and sprite handling have their own var (#81590)
## About The Pull Request
Bodytypes like BODYTYPE_HUMANOID, BODYTYPE_MONKEY, etc that have to do
with the shape of a human body and sprite handling, now have their own
"bodyshape" var instead of being in bodytype along with stuff like
BODYTYPE_ORGANIC, BODYTYPE_ROBOTIC; which have nothing to do with shapes
and sprites
## Why It's Good For The Game
the way these are used in the code is totally different to
BODYTYPE_ROBOTIC, which determine whether you can heal a limb with
medicine etc.
## Changelog
🆑
refactor: Bodytypes to do with character sprite shape now have their own
bodyshape var, all sprite handling is done with bodyshape and not
bodytype anymore
/🆑
2024-02-25 17:34:53 +01:00
..
2023-10-16 16:14:31 +02:00
2023-10-11 16:58:29 -06:00
2023-12-25 13:00:50 +01:00
2024-02-11 03:17:55 +01:00
2023-12-04 14:42:43 -08:00
2023-11-12 09:25:59 +00:00
2023-10-21 23:36:48 +00:00
2024-01-26 02:23:24 +01:00
2023-10-08 03:04:35 +01:00
2023-12-04 14:42:43 -08:00
2023-10-05 13:20:16 -06:00
2023-10-16 16:14:31 +02:00
2023-08-14 12:39:30 -06:00
2023-12-09 13:31:50 +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