MUX server fork


  • Coder

    Been fiddling with my mux fork a bit more. This 'mechanipus' branch is not for general use yet, but:

    If you're a C/C++ developer and/or familiar with UNIX shell operation enough to install a most autoconf style software, keep reading.

    If all of that sounded horrendous, then please wait another few months for something more releasable and user-friendly.

    Some git knowledge may be necessary. I have a fork of MUX up on my github site; there are several branches. 'thereach' tracks more or less what that game is using; likewise darkspires. There's also a mechanipus-rebased-vs-git_dev branch tracking Brazil's latest changes with a few of my handier patches tacked onto the end, for people that like the old ways but want shiny stuff too.

    The 'mechanipus' branch is my dev branch for the moment. It's got some fairly intrusive and incompatible changes now, and I expect there will be many more before I make a release. In particular:

    • Complete rework of the configure/make build system to use autoconf/autoheader/automake/libtool
      • Which means that make doesn't install anything anywhere; you need make install for that.
      • The whole project directory layout is different. There is no game directory anymore, and we don't generally support renaming the game databases and such. netmux it is, and while changing it is trivial, it's too big a source of confusion.
      • Many common options default to yes; realitylvls, stubslave, ssl, inlinessql, etc are all turned off (assuming their libraries are found).
      • As part of the layout change, most help scripts have been renamed.
    • All the patches from my rebase branch;
      • 64k LBUFs
      • BLIND on rooms makes a true quiet room.
      • Command lookups on master room objects consider attributes on their @parents.
      • Bare think does not alter idle time.
    • Additionally:
      • raelik's ATCP (aka GMCP) support.
      • Uses GPerfTools TCMalloc if present to replace the bufferpools.
      • Very different build versioning that uses git.
      • Support for out of tree builds.
      • Initial support for cross-compiled builds. (mingw is broken because of the multitude of VisualC specific #ifdefs, but I'm working on it.)

    Things NOT present but definitely on the must-do list before a release:

    • Complete replacement of the svdhash database implementation. This is a huge amount of work but necessary for where I want to go with it.
    • SQLite support for games running without mysqld handy.

    Plus many other optional goals mentioned in the readme file.

    Sound interesting? Good; please download and break it. I suspect this is still fairly easy as I haven't added the unit test stuff I want yet. Here's what this might look like on a unixy system:

    If you're on, e.g. Debian, try:

    apt-get install build-essential binutils g++ make libgoogle-perftools-dev libssl-dev libmysqlclient-dev
    

    It should work without those libs, but that gives you a more fully featured toy. Additionally, if you are interested in chewing on the code yourself and need to rework the build system, you will want:

    apt-get install autotools automake libtool perl m4 strace gdb
    

    Then:

    $ git clone https://github.com/lashtear/tinymux
    $ cd tinymux/mux/
    $ ./configure --prefix=$HOME/mygame
    $ make -j4 install
    

    If that works, you'll have a game tree in ~/mygame; cd there and take a look at the new layout. You'll probably want to set your path, at least for this session, and load SGP, which would look like:

    PATH=$HOME/mygame/bin:$PATH
    cd ~/mygame/var
    mux-load-flat sgp.flat
    

    Optionally edit ~/mygame/etc/netmux.conf to taste, then

    mux-start
    

    Lemme know where you encounter trouble.

    Known issues:

    • stubslave launch may be broken
    • dbconvert symlink origin on non-symlink platforms (windows?) with out-of-target DESTDIR may break
    • MinGW cross-compliation goes down in flames because of the lingering VisualCisms.
    • I need to write a bunch of manpages.

    Again, this is a developer-preview. Don't use it for actual games, yet. If (when) it breaks, you get to keep both pieces.


  • Coder

    Heyyy. This thing is still alive, and has a variety of fixes.

    Additionally, I've not got a basic set of unit tests (with ever expanding coverage) and per-commit checking via travis-ci. In particular, I can now show things like: Build Status

    Other long-standing mux issues fixed in current mechanipus branch:

    • The inline-sql handler (sql()) will conveniently auto-reconnect whenever needed, completely transparently.

    @Chime said:

    Things NOT present but definitely on the must-do list before a release:

    • Complete replacement of the svdhash database implementation. This is a huge amount of work but necessary for where I want to go with it.
    • SQLite support for games running without mysqld handy.

    Still on the agenda, and in progress! Add to this:

    • Will do a complete rewrite of the SSL layer to clean up some odd cases and allow carrying SSL contexts across @restart.

    Known issues:

    • stubslave launch may be broken

    Fixed!

    • dbconvert symlink origin on non-symlink platforms (windows?) with out-of-target DESTDIR may break

    Should be fixed, difficult for me to test. (And probably no one cares)

    • MinGW cross-compliation goes down in flames because of the lingering VisualCisms.

    Likely dropping windows or at least MSVC support entirely.

    • I need to write a bunch of manpages.

    Yep. And to continue extending the doxygen docs-- but I'm holding off on that as a LOT of the complexity disappears when rewriting certain parts.