* 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>
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.