Files
Bubberstation/code/datums/components
SkyratBot 529b8b4464 [MIRROR] Lighting object oddities [MDB IGNORE] (#21945)
* Lighting object oddities (#76009)

## About The Pull Request

Fire stacks status effect no longer uses a weakref for the mob light, I
am pretty sure there was no real reason to use a weakref there.
Deleted weird luminescent glow dummy, now it just uses the standard
moblight obj.
Put all /obj/effect/dummy/lighting_obj together in a single file and
added a comment explaining why they exist.

(I severely dislike the /obj/effect/dummy typepath, but I am very much
unsure if just replacing all of them with /obj/effect/abstract would
break shit)

## Why It's Good For The Game

Code organization good

* Lighting object oddities

* Update kindle.dm

---------

Co-authored-by: ChungusGamer666 <82850673+ChungusGamer666@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
2023-06-20 14:06:48 -07: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