Files
Bubberstation/code/datums/components
Rob Bailey 044fd3f7ad TGUI-next Nanite Interface Overhaul + Dropdown component (#47972)
* Nanite TGUI-Next + Dropdown

nanite remote

program hub and better remote

fuck it let's make a dropdown component, time to die

DROPDOWN WORKING HOLY SHIT

more dropdown work

cleanup + fixes

new timer system

nanite work

jj

functional dropdown + final structure for backend, more refactor needed

dropdown being insane

oh my god dropdown actually works correctly for once

massive backend refactor

small fix + docs

dropdown optimizations + width

wip nanite cloud control

forgot it

cloud controller

bunch of work

final chamber console

nanite remotes

rebuild

small tweaks

rebuild after rebase

* fixes

* big refactor to useFrontend, use standard style

* whoops

* small changes

* rebuild

* small fixes and tweaks + documentation on dropdown and collapsible

* small tweak to programmer ui

* Cosmetic
2019-12-02 01:00:38 +02:00
..
2019-09-22 03:03:45 -07:00
2019-10-27 16:30:30 -04:00
2019-10-09 01:50:16 -07:00
2019-10-24 18:21:42 -07:00
2019-08-21 11:50:38 +12:00
2019-10-05 13:40:40 -04:00
2019-10-13 16:46:25 +13:00
2019-10-13 14:36:43 +03: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