mirror of
https://github.com/PolarisSS13/Polaris.git
synced 2025-12-14 20:22:42 +00:00
fdabe51ee8
* Adds linter defines to repo. * Uncomments linter defines already in the code. * Resolves unreachable code linter errors. * Nukes decade+ old syndie specops code except for computer since that's mapped in????? * Resolves procs has no parent linter error. * Proc signature fixes * Bad comments * "In" danger * Type safety * Implied nested list abuse * Top level ..() usage * Sleepy coder typos * Invalid kwargs calls * Pointless returns * Linter hacks (see full message) Byond doesn't care and it has no effect but linter doesn't like var/proc for holding references to procs, despite that it's valid byond code. Also, the linter seems to have serious issues figuring out relative proc names. This commit is a sort of take-it-or-leave-it thing. It's not required, it just cuts down on warnings, but this code is valid DM code. * WHATEVER THIS IS * Trick dreamchecker linter into ignoring this file's sins in it's weird use of vars * Fix list decoration syntax - Its a list, not list of lists - To declare that a var is a list you can `var/list/blah = list()` syntax or the `var/blah[0]` syntax. Both do exactly the same thing. But if you do `var/list/blah[0]` that is just like doing `var/list/list/blah = list()` * Hopefully stops the ai holder subtype folder from going quantum and sometimes changes capitalization over time, and incidentally causing 20+ linter errors. * Fixes unwrapped negated object in list linter error. * Resolves colon-like list accessing linter error. * Turns linter on in linter config. * Fixes closet indentation properly and cleans up suit storage unit switch. Co-authored-by: Aronai Sieyes <arokha@arokha.com> Co-authored-by: Leshana <Leshana@users.noreply.github.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.
See this thread for an introduction to the system as a whole.