* 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>
* This is PHASE 1 of a multi-phase conversion. In this first phase we implement the subsystem, but leave it processing the existing global list variables. In the next phase we will switch to use datum variables in the subsystem. The main reason for splitting into two phases is ease of code review; change the meaningful code without the hundreds of machines -> SSmachines.machinery substitutions.
* We did declare macros for adding/removing things to the processing lists, and convert everywhere to use the macros.
* Added var/is_processing to /datum to keep track of whether an instance is already in a processing list (prevents it being in the list twice!) and also debugging, making sure its not in two lists etc.
* NOTE: The global machines list is **no longer sorted** for performance reasons. As far as I know, the only module that actually ever cared was cameras. Our camera system already handles its own sorting in the cameranets anyway, so it should no longer be needed.
