mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-04-05 20:01:51 +01:00
b6ffb1e31b
* Refactor /turf/var/intact (#62331) Turfs have a variable, intact, which conflates three meanings: Determining whether there's something that can be pried out, such as directly with a crowbar or indirectly with a tile stack and a crowbar off-hand. Determining whether underfloor pieces are visible. Determining whether underfloor pieces can be interacted with - by players with tools, through interaction with effects like chemical acid, or foam. When plating is hit with a stack of tiles, /turf/open/floor/attackby checks whether the turf is intact, and if so, ends the attack chain regardless of whether or not the attempt to hotswap a turf (with a crowbar) is successful or not. However, turfs which want the underfloor to be visible - such as catwalks and glass - set the intact variable to FALSE, and so can be repeatedly placed over one another, as if they were the first tile to be placed over the plating. This refactors /turf/var/intact into two distinct variables: /turf/var/overfloor_placed, for whether or not there is something over plating. /turf/var/underfloor_visible, for whether or not the various underfloor pieces should be invisible, visible, or both visible and interactable. All references to /turf/var/intact have been replaced with an equivalent overfloor_placed or underfloor_visible reference, depending on which check is appropriate. underfloor_accessibility can take one of UNDERFLOOR_HIDDEN, UNDERFLOOR_VISIBLE, or UNDERFLOOR_INTERACTABLE. This prevents cases such as acid foam or tools phasing through glass floors to affect the underfloor pieces underneath, and covers all kinds of unusual, not-wiring-visiblity usage such as Holodeck completeness, Revenant interaction, or station integrity checking. * Refactor /turf/var/intact * Thank Co-authored-by: esainane <esainane+github@gmail.com> Co-authored-by: Funce <funce.973@gmail.com>
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.