Files
Bubberstation/code/datums/components
SkyratBot 2c682cf83e [MIRROR] Things that love the station may no longer leave the station, even when Dr. Anomaly says they should. (#8254)
* Things that love the station may no longer leave the station, even when Dr. Anomaly says they should. (#61335)

Bluespace anomalies detonating Move() things. When something is Move()d, none of the logic in forceMove() or doMove() is called, and thus stationloving things can't tell when they've left the z-level (since that's where the logic for it is).

There are a number of approaches I could have taken: Refactoring anomalies to use different movement code. Refactoring Movement code to send more signals in various scenarios. Refactoring the stationloving component.

I settled on two steps. First, refactoring the component to bring it up to modern code standards. Second, moving the logic for COMSIG_MOVABLE_Z_CHANGED to Moved() so the signal always fires regardless of if Move() or forceMove() or doMove() is used, with an optional var for whether the z-change is communicated to contents. This means the ore box was changed to actually send the signal instead of just returning with no parent call or signal sent. Stationloving ore boxes when?

stationloving procs no longer call SIGNAL_HANDLERs directly. Var names are now more descriptive. Things are renamed and documented. At least for the parts of the code I know.

Probably some other code cleanups.

* Things that love the station may no longer leave the station, even when Dr. Anomaly says they should.

Co-authored-by: Timberpoes <silent_insomnia_pp@hotmail.co.uk>
2021-09-18 21:45:42 +01:00
..
2021-06-09 10:44:59 +12: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