Fastmos is Dead
Some Background Info
Let me start by explaining what exactly fastmos is, since a lot of people are incorrect about it. What players call "fastmos" is actually monstermos, implemented in an external DLL called extools. "Fastmos" was coined at some point by someone because in monstermos gasses move, well,
fast... As evidenced by the explosive decompression we all know and love. It's also faster in that the DLL is more performant than BYOND, so it runs faster. This leads to some confusion because fastmos is faster both design-wise and performance-wise, so for the rest of this forum post I'm going just refer to it by its actual name, monstermos.
Why We're Removing It
As I mentioned before, monstermos is part of an external DLL called extools. The devs behind extools reverse-engineered a significant amount of BYOND, to the extent that (among many other useful features) you could have procs defined in DM running code in C++ instead, with none of the overhead of BYOND's extremely inefficient DLL call()() proc (yes, that's the actual syntax). This made it possible to offload CPU-intensive code from BYOND and run it in the C++ DLL instead. In comes monstermos, an atmos implementation written in C++ as part of extools to leverage this increased performance.
However, there's a few problems with this:
- Every new BYOND version had a good chance of breaking extools entirely.
- Atmos is already complicated to begin with, now it was entirely in C++ making it even more complicated.
- Neither the extools devs nor Monster (the creator of monstermos) wanted to maintain their respective parts of it after a while.
- Nobody else with the know-how wanted to maintain it either.
- Let's just say that monstermos isn't particularly well-written, and it was very unstable.
Extools is Dead, Long Live Auxtools
To solve these and other fundamental problems with extools, a complete rewrite was done under the name auxtools, in Rust this time because Rust is the new programming fad. To start with, auxtools requires
as little BYOND reverse-engineering as possible. This means new updates are less likely to break it entirely and when it does break, less effort is required to fix it. There's some other improvements too but you're probably already tired of reading the (oversimplified) technical talk.
Anyways, with auxtools eventually came a new atmos implementation call auxmos, created by Putnam. Auxmos has a lot of pros and cons compared to monstermos:
- It's significantly more performant. I haven't been able to make it actually lag at all no matter how much I stress the server. At its worst it's still faster than monstermos at idle.
- It's more stable and shouldn't cause any server crashes.
- It's not designed after monstermos, it's designed after LINDA, which is TG's atmos. Which means there is no explosive decompression or near-instantaneous gas movements, sadly.
- It's much easier to tweak because some of it is accessible via DM, rather than being entirely in Rust. You can also add new gasses without touching any Rust code.
That being said, the majority of us prefer monstermos and if the auxtools implementation is ever finished we'll be going back to it.
Also, since atmos is now significantly less deadly we're going back to the old full-tile firelocks that require a crowbar to open. On the plus side, malf AIs can crush you to death with them.
tl;dr
We're switching the DLLs that we use for atmos, because the monstermos (aka fastmos) one is unmaintained and unstable and the new one is more performant, even if it's based on TG's atmos and therefore lame. We'll go back to monstermos/fastmos if the opportunity presents itself, since we prefer it.
