Files
Bubberstation/code/datums/components
SkyratBot f02e30a50e [MIRROR] Implements timed_action_flags for do_after-like procs (#1385)
* Implements timed_action_flags for do_after-like procs (#54409)

Originally I wanted to fix an issue where the `get_up()` `do_after()` would ignore the callback checks, because it was `uninterruptible`, so that made me refactor these procs to allow for higher granularity on checks and standardize behavior a bit more.
There's more work to be done for them, but one thing at a time.

* Removes the `uninterruptible` check in favor of the more granular `timed_action_flags`
* Cleans code on the `do_atom`, `do_after_mob`, `do_mob` and `do_after` procs to standardize them a little better.

* Implements timed_action_flags for do_after-like procs

* Update horror_form.dm

Co-authored-by: Rohesie <rohesie@gmail.com>
Co-authored-by: Azarak <azarak10@gmail.com>
2020-10-21 07:06:03 +02:00
..
2020-09-07 03:52:59 +02:00
2020-09-07 03:52:59 +02:00
2020-08-19 04:48:14 +02:00
2020-09-07 03:52:59 +02: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.

See this thread for an introduction to the system as a whole.

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