* Macros multi-z code, removes the false premise of manual offsets (#76248)
## About The Pull Request
[Removes the pretense of relative multiz
levels](0293fdc2bd)
Our multiz system does not support having a z level that is only
connected one way, or which goes down backwards or anything like that.
That's a fiction of the trait system, the actual backend has never
really supported this.
This pr removes the assumptions we were making backend around this, and
uses that to save cpu time.
I am also converting multiz_levels from an assoc list to a pure one,
which saves significantly on access times and cleans up the code
somewhat.
Also I'm making the get_below/get_above procs into macros, for the sake
of cpu time.
[Converts the starlight disease to use BYOND's directional defines
instead of our
own](7d698f02d9)
To some extent spurred on by
https://github.com/DaedalusDock/daedalusdock/pull/298, tho it was known
before
## Why It's Good For The Game
Faster multiz code, faster init, etc etc etc
* modular files how very dare you
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Basic multiZ mob movement procs (Observers can always move)
Open space, showing what things are below it, and everything that entails. No complex support for dynamic generation just yet.
Decide how openspace should look :/
Atoms falling through open space (NO MOB SUPPORT/DAMAGE/ANYTHING YET.)
//CANCELLED FOR ANOTHER PR - [ ] Being able to see upwards? Downwards is going to be handled by open space.
MultiZ tile atmospherics - EDIT: Working demo! https://puu.sh/B7mUs/3f6274740f.mp4
Bugtest the heck out of this trainwreck.
