Dreams to Reality

[Ashen-Shugar]

Ok peeps.

This is something I've rolled around in my head, and figured I"d put it out there for everyone else to talk about and debate.

To make a good game that people want to build, one of the important things is to have a back--end engine, weither that is mush, mud, muse, moo, evennia, muck, or other that works best for matching your dreams.

What I want to bring up to you guys (and girls) is this:

What is your favorite mu* engine, the pros you like the most with it, and the cons that you wish it could do.

I have an alternative motive with this, as I plan to take anything and everything said to help make RhostMUSH even better, but beside this, I'm hoping this will bring to light to everyone, developers, game admins, and players alike, to what is really desired today in a gaming engine.

Also, to highlight some things that's currenty in the works with RhostMUSH so those of you can bring up info on that as well or pros/cons, here is where we are:

• unicode/UTF8 -- Beta. It's already there in a branch (Kage) and just has to be final-tested and pushed into the main branch.
• python API -- Preliminary development. There's no real backend code for it yet but the design implementation is solid and we just have to do it. This will essentially do a multi-threaded API engine that will allow a server-side python scripting to be tagged and interpreted right into the core MUSH. So all the power of python with the pre-existing mush language.
• With the above, a future ruby, perl, and other possible scripting languages tied to the same (or similar) api will be possible.
• HSpace and hopefully a sync of ASpace compatibility. HSpace is already working in a branch.

That's currently what's cooking with RhostMUSH.

For all other people, please let everyone know their favorite codebase and pros/cons to those and let's discuss how to make our love even better.

[ixokai]

More years ago then I can properly count (but something very close to 15-20, exact timing I'm lacking), I was on a game called Armageddon. The game was about Angels, Demons, and humans: about the Blessed, the Damned, the Chosen. This game started out on another actual server, but got migrated to its own existence at some point before I became involved with it.

I was a child and deeply invested in this game. Someone on this game loved me (he thought I was a girl at first, later didn't care when I wasn't, the drama here is everything you can imagine for a game where I'm like maybe 16 at the oldest at this point).

I've always been something of a nerd. Somehow, I became site-admin for this game. I upgraded it to a new version. It was, originally, a game firmly set in TinyMUSH 2.2.

Why? Because shiny.

(What is shiny? I want to swear its TinyMUSH3 but I can't remember for sure so make no accusations. It was an upgrade from TinyMUSH 2.2 for sure) Anyways.

The corruption started.

Exits sent you places exits were not set to. You examine an object and see things on it that should not be there. The game was before my eyes dissolving.

I logged onto some game, I don't even remember which-- but it was something like MUS*H, MPUG, or similar developer centered game-- and asked for help on a channel.

Ashen-shugar answered: Rhost could load this database and fix its problems. While any errors that existed would still exist, it wouldn't get worse.

This seemed like a godsend, as weirdness was increasing almost with every minute.

I set up Rhost.

I had some questions, and Ashen answered them.

I loaded Armageddon's database, and made the major announcement of the transition, and...

Armageddon was fine.

It ran at least-- at //least//-- two years after the conversion where it was boiling itself alive in corruption in its original server.

Man, the faith.

I can not tell you how firm the faith has been since then. I think Rhost, I think two things-- and one is directly from that point of my life that decade and a half ago-- one? I can trust it.

Two? This I got as I became a more sophisticated coder. Rhost is a toolbox that gives me, the coder, all the toys I could ever need.

I decided a couple years ago I only "code" for Rhost games, because things like... say... its printf function (not to be confused with C's printf, but similar in intent) are revolutionary in what I can achieve vs what I want to happen. To say that's the only point is minor: SO many distinct features Rhost allows are exceptional from a coder's POV.

As it turns out, my dedication isn't perfect and I've recently agreed to code for a pair of PennMUSH games because... reasons. (Faraday's +combat is really, seriously, honestly, a better approach to mass combat then anyone's ever done before in the genre)

But still, on my own project, Rhost is the only answer for me. Rhost is reliable. Fast. Capable. But Reliable. I'll never forget that first interaction with Armageddon. A game I loved was dying, literally, and lasted for years after the conversion.

I trust Rhost.

IMHO.

[Apos]

@ixokai Conversations about code bases shouldn't give me feels.

[Thenomain]

TinyMUX. It has the most I need and the player base I want to code for. I wish it had about, mm, three or so Penn/Rhost features, but that's about it.

Rhost players, Mux players, and Tiny players seem to be cut from the same cloth, but there's something about playing on Penn that rubs me the wrong way. I would follow Javalin into code nirvana, but playing on Penn is like wearing a horse-hair shirt inside-out. And the channel system. Holy crap, that channel system is worse than what we used to use for mail before @mail. (Myrddin's Firelizard Mail ring anyone's bell?)

Even stock TinyMUX is not my preferred system anymore, as @Chime has opened up hard-coded limitations and fixed the bugs that opening these limits revealed. (I would crash The Reach about once a week before she fell to my cute puppy dog eyes and fixed it.) I haven't looked into Rhost lately, but last time I tried to run a stat system as data-heavy as WoD, it looked at me like I was trying to solve world hunger in Perl.

I think I lost sight of the question. Er, yes, all of the above. USA! USA!

[Rook]

Rhost. But you knew my answer.

[Chime]

I really like RHost; it was what was used by the first "major" game I played on (Haunted Memories). I found the maintainer to be kind and attentive to fixing problems when reported. (heh, tho to be fair I usually report that kind of trouble in the form of a patch-- but @Ashen-Shugar is good people either way).

RHost has a lot of nice hardcode functions that the others don't have, but it's been a while so listing them might be tricky. This brings us to, of course, Why-Chime-Hasn't-Been-Using-RHost: (Quite a lot of these are no longer relevant!)

• No unicode support (apparently fixed in beta?)

• Zenty's color implementation - most MUSH codebases with colored strings internally implement them with various sorts of control codes inside the string and transparently hide them from length() and friends. The color implementation on RHost is not so transparent, and has a number of odd glitches with respect to escaping and evaluation layers. Not a security hazard, but annoying. Also, no 256color or html color.

• The database used for disk storage - Like most MUSHes, it's intimately tied to its DB implementation all through the code and unfortunately the one used in RHost sucks.
  The biggest, most crippling limitation I hit was inability to raise LBUF size. MUX defaults to 8000, my MUX branch defaults to 64000. RHost uses 3999 and can't change without a major overhaul. A properly coded game shouldn't necessarily need more than 3999 byte LBUFs, but inevitably people want to use some crap MUSH app that wasn't designed to scale. Apps in this category:

  • Anomaly Jobs
  • Myrddin's BBoards
  • Most chargens ever written
  • I.e. everything

  Games like The Reach, etc would never have been possible on 3999 byte lbufs. On HM, I can definitively state that the LBUF limits crippled the jobs system so badly that staff frequently burned out trying to rush through jobs just to clear up space. AJ just doesn't scale.

• Closed-source, NDA required - very much no longer relevant, but it was initially a bit off-putting. I can understand why they did it and can confirm that it never stood in the way of getting anything done. It did make this shy octopus a bit more timid about contributing initially, but it's publicly available now.

• Loss of the original project repo, issue tracking. (Sorry for bringing this up again, really!) RHost's dev host had a disk incident and the svn repo was lost. We have a few sporadic tarballs of various releases, and this does not impact writing/fixing code, but the historical perspective of who changed what when is gone. This... makes me sad. As people have seen in other threads, I take great delight in the archaeological software process and losing that hurts. Also it makes the sysadmin/data-archivist side of me shudder with visceral horror.

RHost also is somewhat notorious for UI differences in @mail and the soft-channels. I liked both of those things though, and I suspect it's mostly an issue of what you learned on.

What is your favorite mu* engine, the pros you like the most with it, and the cons that you wish it could do.

TinyMUX is where I've been for a while. Brazil and Sparks are fantastic to work with.

As for my MUX branch and what it does different: lots of work on making a smoother autoconf/libtool and install process. In particular, you use ./configure and it will put things where you set the --prefix when you say make install. Most other codebases manage to screw this up horribly. Example deployment workflow:

$ git clone https://github.com/lashtear/tinymux.git
Cloning into 'tinymux'...
remote: Counting objects: 59420, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 59420 (delta 0), reused 0 (delta 0), pack-reused 59418
Receiving objects: 100% (59420/59420), 18.39 MiB | 18.38 MiB/s, done.
Resolving deltas: 100% (46769/46769), done.
Checking connectivity... done.
$ cd tinymux/mux
$ ./configure --prefix=$HOME/KowloonByNight
checking for ...

... thousands of lines ... It auto-enables SSL and MySQL/MariaDB support if found, as well as defaulting-on for RealityLvls and such, plus I can do parallel and out of tree builds with correct dependency tracking and build isolation. Beautiful for CI testing!

$ make -j8
make  all-am
make[1]: Entering directory '/home/lucca/src/t/tinymux/mux'
  CXX      libversion_a-version.o
  CXX      libmux.lo
  CC       libltdl/lt__strl.lo
  CXX      funcs.lo
  CXX      sqlslave.lo
  CXX      sample.lo
  CXX      sqlproxy.lo
  CXX      sum.lo

... it builds, hiding most options by default so warnings are immediately obvious. Even better, it DOES NOT INSTALL on build. When it is time to install, you can do so with make install. Note that you can set DESTDIR to do an installation built for --prefix but sent to a different place, e.g. for packaging. Likewise --prefix and --exec-prefix can be different places to facilitate having several game instances share the same executables/libs.

$ make install
make  install-am
make[1]: Entering directory '/home/lucca/src/t/tinymux/mux'
make[2]: Entering directory '/home/lucca/src/t/tinymux/mux'
 /bin/mkdir -p '/home/lucca/KowloonByNight/bin'
... ...
make  install-data-hook
make[3]: Entering directory '/home/lucca/src/t/tinymux/mux'
  CHKCONF  /home/lucca/KowloonByNight/bin
    CP     mux-backup
    CP     mux-backup-flat
    CP     mux-load-flat
    CP     mux-unload-flat
    CP     mux-start
    CP     mux-stop
  CHKCONF  /home/lucca/KowloonByNight/etc
    CP     alias.conf
    CP     art.conf
    CP     compat.conf
    CP     netmux.conf
    CP     script.conf
  CHKCONF  /home/lucca/KowloonByNight/etc/text
    CP     badsite.txt
    CP     connect.txt
    CP     create_reg.txt
...

Of special note here: It installs config files carefully, so that reinstalling on top of an existing game does not wipe out your configs. (Yeah, sorry @Thenomain) Also: the tree structure it uses matches other standard UNIX fs naming hierarchies. Sadly, this seems to confuse the hell out of everyone not-me, but I thought it was a huge huge improvement:

$ cd ~/KowloonByNight/
$ ls
bin  etc  lib  libexec  share  var
$ ls -lR
.:
total 24
drwxr-xr-x 2 lucca lucca 4096 Jun 30 14:24 bin
drwxr-xr-x 3 lucca lucca 4096 Jun 30 14:24 etc
drwxr-xr-x 3 lucca lucca 4096 Jun 30 14:24 lib
drwxr-xr-x 2 lucca lucca 4096 Jun 30 14:24 libexec
drwxr-xr-x 3 lucca lucca 4096 Jun 30 14:24 share
drwxr-xr-x 2 lucca lucca 4096 Jun 30 14:24 var

./bin:
total 48
lrwxrwxrwx 1 lucca lucca   41 Jun 30 14:24 dbconvert -> /home/lucca/KowloonByNight/libexec/netmux
-rwxr-xr-x 1 lucca lucca 1474 Jun 30 14:24 mux-backup
-rwxr-xr-x 1 lucca lucca 1474 Jun 30 14:24 mux-backup.default
-rwxr-xr-x 1 lucca lucca 1169 Jun 30 14:24 mux-backup-flat
-rwxr-xr-x 1 lucca lucca 1169 Jun 30 14:24 mux-backup-flat.default
-rwxr-xr-x 1 lucca lucca  481 Jun 30 14:24 mux-load-flat
-rwxr-xr-x 1 lucca lucca  481 Jun 30 14:24 mux-load-flat.default
-rwxr-xr-x 1 lucca lucca 1240 Jun 30 14:24 mux-start
-rwxr-xr-x 1 lucca lucca 1240 Jun 30 14:24 mux-start.default
-rwxr-xr-x 1 lucca lucca  792 Jun 30 14:24 mux-stop
-rwxr-xr-x 1 lucca lucca  792 Jun 30 14:24 mux-stop.default
-rwxr-xr-x 1 lucca lucca  493 Jun 30 14:24 mux-unload-flat
-rwxr-xr-x 1 lucca lucca  493 Jun 30 14:24 mux-unload-flat.default

./etc:
total 76
-rw-r--r-- 1 lucca lucca 19917 Jun 30 14:24 alias.conf
-rw-r--r-- 1 lucca lucca 19917 Jun 30 14:24 alias.conf.default
-rw-r--r-- 1 lucca lucca   391 Jun 30 14:24 art.conf
-rw-r--r-- 1 lucca lucca   391 Jun 30 14:24 art.conf.default
-rw-r--r-- 1 lucca lucca  2696 Jun 30 14:24 compat.conf
-rw-r--r-- 1 lucca lucca  2696 Jun 30 14:24 compat.conf.default
-rw-r--r-- 1 lucca lucca  1863 Jun 30 14:24 netmux.conf
-rw-r--r-- 1 lucca lucca  1863 Jun 30 14:24 netmux.conf.default
-rw-r--r-- 1 lucca lucca   813 Jun 30 14:24 script.conf
-rw-r--r-- 1 lucca lucca   813 Jun 30 14:24 script.conf.default
drwxr-xr-x 2 lucca lucca  4096 Jun 30 14:24 text

./etc/text:
total 1408
-rw-r--r-- 1 lucca lucca    130 Jun 30 14:24 badsite.txt
-rw-r--r-- 1 lucca lucca    130 Jun 30 14:24 badsite.txt.default
-rw-r--r-- 1 lucca lucca    629 Jun 30 14:24 connect.txt
-rw-r--r-- 1 lucca lucca    629 Jun 30 14:24 connect.txt.default
-rw-r--r-- 1 lucca lucca     94 Jun 30 14:24 create_reg.txt
-rw-r--r-- 1 lucca lucca     94 Jun 30 14:24 create_reg.txt.default
-rw-r--r-- 1 lucca lucca    152 Jun 30 14:24 down.txt
-rw-r--r-- 1 lucca lucca    152 Jun 30 14:24 down.txt.default
-rw-r--r-- 1 lucca lucca    170 Jun 30 14:24 full.txt
-rw-r--r-- 1 lucca lucca    170 Jun 30 14:24 full.txt.default
-rw-r--r-- 1 lucca lucca    558 Jun 30 14:24 guest.txt
-rw-r--r-- 1 lucca lucca    558 Jun 30 14:24 guest.txt.default
-rw-r--r-- 1 lucca lucca 454762 Jun 30 14:24 help.txt
-rw-r--r-- 1 lucca lucca 454762 Jun 30 14:24 help.txt.default
-rw-r--r-- 1 lucca lucca      0 Jun 30 14:24 motd.txt
-rw-r--r-- 1 lucca lucca      0 Jun 30 14:24 motd.txt.default
-rw-r--r-- 1 lucca lucca     43 Jun 30 14:24 news.txt
-rw-r--r-- 1 lucca lucca     43 Jun 30 14:24 news.txt.default
-rw-r--r-- 1 lucca lucca    416 Jun 30 14:24 newuser.txt
-rw-r--r-- 1 lucca lucca    416 Jun 30 14:24 newuser.txt.default
-rw-r--r-- 1 lucca lucca  22754 Jun 30 14:24 plushelp.txt
-rw-r--r-- 1 lucca lucca  22754 Jun 30 14:24 plushelp.txt.default
-rw-r--r-- 1 lucca lucca     29 Jun 30 14:24 quit.txt
-rw-r--r-- 1 lucca lucca     29 Jun 30 14:24 quit.txt.default
-rw-r--r-- 1 lucca lucca    556 Jun 30 14:24 register.txt
-rw-r--r-- 1 lucca lucca    556 Jun 30 14:24 register.txt.default
-rw-r--r-- 1 lucca lucca  16346 Jun 30 14:24 staffhelp.txt
-rw-r--r-- 1 lucca lucca  16346 Jun 30 14:24 staffhelp.txt.default
-rw-r--r-- 1 lucca lucca 173366 Jun 30 14:24 wizhelp.txt
-rw-r--r-- 1 lucca lucca 173366 Jun 30 14:24 wizhelp.txt.default
-rw-r--r-- 1 lucca lucca      0 Jun 30 14:24 wizmotd.txt
-rw-r--r-- 1 lucca lucca      0 Jun 30 14:24 wizmotd.txt.default
-rw-r--r-- 1 lucca lucca     61 Jun 30 14:24 wiznews.txt
-rw-r--r-- 1 lucca lucca     61 Jun 30 14:24 wiznews.txt.default

./lib:
total 84
-rwxr-xr-x 1 lucca lucca  1021 Jun 30 14:24 libmux.la
-rwxr-xr-x 1 lucca lucca 77296 Jun 30 14:24 libmux.so
drwxr-xr-x 2 lucca lucca  4096 Jun 30 14:24 tinymux

./lib/tinymux:
total 280
-rwxr-xr-x 1 lucca lucca  1065 Jun 30 14:24 funcs.la
-rwxr-xr-x 1 lucca lucca 37072 Jun 30 14:24 funcs.so
-rwxr-xr-x 1 lucca lucca  1071 Jun 30 14:24 sample.la
-rwxr-xr-x 1 lucca lucca 61064 Jun 30 14:24 sample.so
-rwxr-xr-x 1 lucca lucca  1083 Jun 30 14:24 sqlproxy.la
-rwxr-xr-x 1 lucca lucca 40896 Jun 30 14:24 sqlproxy.so
-rwxr-xr-x 1 lucca lucca  1083 Jun 30 14:24 sqlslave.la
-rwxr-xr-x 1 lucca lucca 77832 Jun 30 14:24 sqlslave.so
-rwxr-xr-x 1 lucca lucca  1053 Jun 30 14:24 sum.la
-rwxr-xr-x 1 lucca lucca 38968 Jun 30 14:24 sum.so

./libexec:
total 5700
-rwxr-xr-x 1 lucca lucca 5769576 Jun 30 14:24 netmux
-rwxr-xr-x 1 lucca lucca   18872 Jun 30 14:24 slave
-rwxr-xr-x 1 lucca lucca   44072 Jun 30 14:24 stubslave

./share:
total 4
drwxr-xr-x 3 lucca lucca 4096 Jun 30 14:24 doc

./share/doc:
total 4
drwxr-xr-x 2 lucca lucca 4096 Jun 30 14:24 tinymux

./share/doc/tinymux:
total 136
-rw-r--r-- 1 lucca lucca  3975 Jun 30 14:24 ATTACK
-rw-r--r-- 1 lucca lucca  2238 Jun 30 14:24 BACKUPS
-rw-r--r-- 1 lucca lucca  1786 Jun 30 14:24 CHANGES
-rw-r--r-- 1 lucca lucca  6675 Jun 30 14:24 CONFIGURATION
-rw-r--r-- 1 lucca lucca  2209 Jun 30 14:24 CONVERSION
-rw-r--r-- 1 lucca lucca  3176 Jun 30 14:24 CREDITS
-rw-r--r-- 1 lucca lucca  2298 Jun 30 14:24 DISTRIBUTIONS
-rw-r--r-- 1 lucca lucca  2467 Jun 30 14:24 GUESTS
-rw-r--r-- 1 lucca lucca  4750 Jun 30 14:24 INSTALL
-rw-r--r-- 1 lucca lucca  3713 Jun 30 14:24 LIMITS
-rw-r--r-- 1 lucca lucca  5624 Jun 30 14:24 LOCAL
-rw-r--r-- 1 lucca lucca  4373 Jun 30 14:24 MEMORY
-rw-r--r-- 1 lucca lucca  1820 Jun 30 14:24 MODULES
-rw-r--r-- 1 lucca lucca  4237 Jun 30 14:24 NOTES
-rw-r--r-- 1 lucca lucca  7892 Jun 30 14:24 README
-rw-r--r-- 1 lucca lucca  5734 Jun 30 14:24 readme.txt
-rw-r--r-- 1 lucca lucca   791 Jun 30 14:24 REALITY
-rw-r--r-- 1 lucca lucca 14318 Jun 30 14:24 REALITY.SETUP
-rw-r--r-- 1 lucca lucca  6018 Jun 30 14:24 REALMS
-rw-r--r-- 1 lucca lucca  1710 Jun 30 14:24 SGP
-rw-r--r-- 1 lucca lucca  4225 Jun 30 14:24 SQL
-rw-r--r-- 1 lucca lucca  2570 Jun 30 14:24 SSL

./var:
total 60
-rw-r--r-- 1 lucca lucca 59692 Jun 30 14:24 sgp.flat

So lots of build changes, mostly, including a very young set of regression tests in the tests/ tree; see here for an example; it uses the standard TAP harness and telnet+Expect to validate a bunch of features. Sadly the coverage report is still pretty sparse-- but I'm LOOKING at it which is something most other codebases aren't doing as best I can tell.

I'm happy to answer questions about autoconf/libtool, git, github, CI with travis, etc., for codebases interested in exploring those things, but my primary devwork currently is pointed at MOO stuff.

I do agree adding Python support in-MUSH is a fantastic way to finally drag the community kicking-and-screaming away from mushcode. It needs to be done.

[faraday]

I've always used PennMUSH. No special reason, it's just what I learned on and it was too much of a pain to deal with the subtle differences with the others when coding. Everyone who complains about PennMUSH channels? That's me when I'm on a MUX game... OMG HOW DO I TALK?!?! Many things that we think are "intuitive" are only that way because it's what we're most familiar with.

My only requirement for a new MUSH server is that it not use MUSHCode. Seriously. I never ever want to touch another line of that stuff ever again.

(This is not to slam MUSHCode. For 80's era technology it's a pretty powerful scripting language. But by modern standards? It's like trying to code a web app in assembly language. Insanity.)

[Thenomain]

@faraday

... I like assembly.

[Ashen-Shugar]

@Chime

Hey Chime. Rhost has grown a lot since you last played with it.

To answer some of your questions in order...

• No unicode support (apparently fixed in beta?)
  -- Correct. This is fixed in a 'Kage' branch which is undergoing final testing. It uses a markup language similar to how ansi works.

• Zenty's color implementation
  -- This has gotten a lot more transparent and become integrated in a lot of commands and functions. So it's a lot cleaner than it used to be. Still no HTML color but we do full XTERM 256 color and it allows ansi(<R G B>,foo) encoding and downtalks to 256 color (fully MUX/Penn ansi() compatible).

• Loss of the original project repo, issue tracking
  -- Oh yes this sucked so hard. I went through and backtracked as many changes and suggestions that I could, and it's now part of the main distro and online help in 'help revis' shows all the changes that I was able to back port since version 1.0.0 in 1989. It's not perfect, but it's everything I could find

• @mail UI changes.
  -- We have wrappers for @mail now that will mimic MUX/TM3 or Penn's system fairly reliably. It's not 100%, but it's good enough that people seem comfortable with it.

• The database used for disk storage
  -- QDBM is now the default database engine and we allow upwards to 64K LBUFS. In addition, you can increase -and- decrease the LBUF's in a live database without introducing corruption. It does auto-trimming. You would potentially lose data that was larger than the new buffer, but the db handles it fine w/o eating itself. We also natively support mysql and sqlite... at the same time optionally.

• The method to compile Rhost. We now use a menu

                       RhostMUSH Source Configuration Utility

------------------------------------------------------------------------------
[X]  1. Sideeffects        [X]  2. MUSH/MUX u()/zfun  [X]  3. MUX inc()/dec()
[X]  4. Disabled Comsys    [#]  5. ANSI SUBS (menu)   [X]  6. crypt()/decrypt()
[X]  7. +help hardcoded    [X]  8. MUX @program       [ ]  9. COMMAND flag
[X] 10. ~/_ attributes     [X] 11. Reality Levels     [X] 12. a-z setq support
[X] 13. Enhanced ANSI      [X] 14. Marker Flags       [X] 15. Bang support
[ ] 16. Alternate WHO      [X] 17. Old SETQ/SETR      [X] 18. Secured Sideeffects
[ ] 19. Disable DebugMon   [ ] 20. Disable SIGNALS    [ ] 21. Old Reality Lvls
[ ] 22. Read Mux Passwds   [ ] 23. Low-Mem Compile    [ ] 24. Disable OpenSSL
[X] 25. Pcre System Libs   [X] 26. SHA512 Passwords
--------------------------- Beta/Unsupported Additions -----------------------
[#] B1. MySQL Support      [ ] B2. Door Support(Menu) [X] B3. 64 Char attribs
[ ] B4. SQLite Support     [X] B5. QDBM DB Support    [#] B6. LBUF Settings (Menu)
------------------------------------------------------------------------------

Keys: [h]elp [i]nfo [s]ave [l]oad [d]elete [c]lear [m]ark [b]rowse [r]un [q]uit
      [x]tra default cores (MUX, TinyMUSH3, Penn, Rhost-Default)
      Or, you may select a numer to toggle on/off

Please Enter selection:

Rhost has grown up quite nicely from the fuzzy days of yonder-year.

[Thenomain]

@Ashen-Shugar

Does the menu allow me to globally turn off the cutesy "Did you mean Help?" style error messages which, okay, I've always found demeaning. That's just me, mind you. Sometimes when I forget I'm logging into an Rhost that message set set me scrambling to remember what's a flag and what's a trigger and what knife at the dinner table is best to plunge into my eyeballs so I never had to see it again.

edit: That reminds me, what I want out of my Mu* is things to be more consistent. What's a flag on one game is a toggle on another? No. None of that. No more of that. What the hell is a "toggle" anyway? Oh, it's a preference? But on some games it's a flag? Quiddit.

And no, I didn't mean "allow players to turn off annoying help messages", but "menu-driven kill it dead with a pitchfork".

edit on edit: This is why I think Penn, tho having the older chat system, has the worse of the two between Penn and Mux. It involves the kind of laissez faire approach to systems that Mushes suffer from. It may be better featured, but I don't believe it to be better presented.

final edit: Which may be the source of my "hair shirt" feeling when dealing with Penn. Again, A+++ to Javelin and Faraday and so on, but I sometimes can't shake the feeling that there is an undercurrent of professional superiority from other Penn coders based on what appears to me to be nothing more than feature set. I dunno.

[Ashen-Shugar]

@Thenomain said in Dreams to Reality:

@Ashen-Shugar

Can I turn off the cutesy "Did you mean Help?" style error messages which, okay, I've always found demeaning. That's just me, mind you. Sometimes when I forget I'm logging into an Rhost that message set set me scrambling to remember what's a flag and what's a trigger and what knife at the dinner table is best to plunge into my eyeballs so I never had to see it again.

Yup!

> help vanilla_errors
VANILLA_ERRORS TOGGLE
  Toggle: VANILLA_ERRORS

  When this toggle is set on an object, the mush will show that object
  the normal error message. Otherwise the mush will show something more
  creative.

> @toggle me=vanilla_errors

You can also globally modify the errors.txt file and either null it out (which defaults to the vanilla error) or modify what you want for it.

Full compatibility is for the win

Edit: Wellll.... the reason for the @toggles was two fold. It was intended for 'toggle' values that was meant to turn on/off features on the fly, and the other was we reached the maximum for internal flag markers for the word storage at the time.

[faraday]

@Thenomain said in Dreams to Reality:

final edit: Which may be the source of my "hair shirt" feeling when dealing with Penn. Again, A+++ to Javelin and Faraday and so on, but I sometimes can't shake the feeling that there is an undercurrent of professional superiority from other Penn coders based on what appears to me to be nothing more than feature set. I dunno.

I don't really interact with other Penn devs, so I can only speak for myself. I don't see Penn as superior to MUX. It's just different. There are a few things that Penn has but MUX doesn't, and vice-versa, but they're largely identical. As a player, the differences are mild annoyances (like fumbling around to try and set up com aliases to mimic Penn's system). As a coder, though, the differences remind me too much of browser compatibility crap, requiring workarounds for stuff that's different just 'cause it's different. Dealing with that is just too much like work.

[Griatch]

@Ashen-Shugar

python API -- Preliminary development. There's no real backend code for it yet but the design implementation is solid and we just have to do it. This will essentially do a multi-threaded API engine that will allow a server-side python scripting to be tagged and interpreted right into the core MUSH. So all the power of python with the pre-existing mush language.

This sounds awesome, kudos for giving more Python to the people! It will be interesting to see how the Python API will look. Also, when you say "multi-threaded", how do you intend to do true multi-threading rather than asynchronous event-loops without hitting the GIL - or are you referring to launching multiple python interpreters in separate processes?

... but anyway, to stay on topic, I'm partial to Evennia but that's maybe not too much of a surprise to anyone.
.
Griatch

[Ashen-Shugar]

@Griatch said in Dreams to Reality:

@Ashen-Shugar

python API -- Preliminary development. There's no real backend code for it yet but the design implementation is solid and we just have to do it. This will essentially do a multi-threaded API engine that will allow a server-side python scripting to be tagged and interpreted right into the core MUSH. So all the power of python with the pre-existing mush language.

This sounds awesome, kudos for giving more Python to the people! It will be interesting to see how the Python API will look. Also, when you say "multi-threaded", how do you intend to do true multi-threading rather than asynchronous event-loops without hitting the GIL - or are you referring to launching multiple python interpreters in separate processes?

... but anyway, to stay on topic, I'm partial to Evennia but that's maybe not too much of a surprise to anyone.
.
Griatch

Multi-threaded in that the python scripting will launch separately from the mush engine.

So you submit a request to the API and it then goes off and executes its thing then when finished returns the values and results to the mush with a notification layer.

There'll be two methods. A single-instance (works like a built in function) and a multi-instance (or multi-thread) that will work a bit like the built in semaphores.

So one instance is layer -> python -> result

The other instance is layer -> python -V -> continue -> python -^ -> result

Where you start by (V) pushing out the request to the python, and at some later point you get a notification state (^) saying the result is complete.

[Griatch]

@Ashen-Shugar said in Dreams to Reality:

Multi-threaded in that the python scripting will launch separately from the mush engine.

So you submit a request to the API and it then goes off and executes its thing then when finished returns the values and results to the mush with a notification layer.

There'll be two methods. A single-instance (works like a built in function) and a multi-instance (or multi-thread) that will work a bit like the built in semaphores.

So one instance is layer -> python -> result

The other instance is layer -> python -V -> continue -> python -^ -> result

Where you start by (V) pushing out the request to the python, and at some later point you get a notification state (^) saying the result is complete.

Thanks for the elaboration! So to translate to terms I'm more familiar with, you will offer one sequential in-process call (which is blocking I presume) and also one asynchronous version involving a call to python running in a subprocess (or even launching a new python instance per call?) with a callback for whenever it returns. Sounds good!
.
Griatch

[Fantom]

Rhost. And I've been on the fence but @Ashen-Shugar always pulled me back towards the light.

I just the love the fact that when they update the main branch, I type /update and it automatically patches in the new code and reloaded the mush...seamlessly....thanks Ash

I'm also running the branch with HSpace...and its stable...with almost 80+ days uptime...

Now I absolutely love faradays fs3....if there was only a way to convert it to weg d6...I'd drop dahans code in a heartbeat (no offense to dahan)

[Ashen-Shugar]

@Griatch said in Dreams to Reality:

Thanks for the elaboration!

My pleasure

So to translate to terms I'm more familiar with, you will offer one sequential in-process call (which is blocking I presume) and also one asynchronous version involving a call to python running in a subprocess (or even launching a new python instance per call?) with a callback for whenever it returns. Sounds good!

As far as I'm aware, that's what the plan is. The async will essentially run a separate thread for each python call, so each async call runs its own sandboxed process.

Eventually what I would love to do with this as well is once we got the environment set up to be able to work with Evennia and exchange python modules so that we could literally swap them on the fly between our codebases like plugins.

But that's the distant future.

[Griatch]

@Ashen-Shugar said in Dreams to Reality:

Eventually what I would love to do with this as well is once we got the environment set up to be able to work with Evennia and exchange python modules so that we could literally swap them on the fly between our codebases like plugins.

But that's the distant future.

That's a cool idea, a bigger body of generic MU*-related python modules can only be good for everyone. Realistically I suspect Evennia's command-system (dynamically combining cmdsets) works so differently from Rhost that it would likely be hard to use many of our command-based plugins as-is. In the same way, our objects are inherently tied to our database schema. So if one wanted to use those one would need, I don't know, some sort of emulation layer ...?

Rules-modules and text-manipulation utilities that are not tied to Evennia's commands or database could probably be adapted more easily though - and vice versa similar types of Python modules made for Rhost could probably be adapted for Evennia.

Worth to keep in mind as your development continues. Let me/us know if you want to compare notes at some point.
.
Griatch

[Chime]

@Ashen-Shugar said in Dreams to Reality:

• The database used for disk storage
  -- QDBM is now the default database engine and we allow upwards to 64K LBUFS. In addition, you can increase -and- decrease the LBUF's in a live database without introducing corruption. It does auto-trimming. You would potentially lose data that was larger than the new buffer, but the db handles it fine w/o eating itself. We also natively support mysql and sqlite... at the same time optionally.

Nice!

• The method to compile Rhost. We now use a menu

                       RhostMUSH Source Configuration Utility

------------------------------------------------------------------------------
[X]  1. Sideeffects        [X]  2. MUSH/MUX u()/zfun  [X]  3. MUX inc()/dec()

It's very pretty-- but it's a perfect example of what I was trying to avoid. I've been a UNIX person since 1995. I really do want just bare autoconf so that I can automate and do CI testing more easily.

That said-- it is really nice to have all of those configurable features. Ideally they should become config options in the game conf file rather than compile-time features, but I understand quite well how big a pain that is.

Admittedly, a lot of my customizations to MUX were to remove a lot of #ifdefs for obsolete crap.

Take your MUX inc()/dec() option. What's the harm in having that always enabled?

[X] 26. SHA512 Passwords

I hope those are still salted?

[Ashen-Shugar]

@Chime said in Dreams to Reality:

It's very pretty-- but it's a perfect example of what I was trying to avoid. I've been a UNIX person since 1995. I really do want just bare autoconf so that I can automate and do CI testing more easily.

Well, that's the brilliant part of it. It makes a dynamic file called 'custom.defs' in the src directory that has the Makefile variables. So you could use CLI and generate it in a batch or on the fly just fine. The menu is just an interface to generate the custom.defs file, that's it.

Unix guy here since 1985 (AT&T SYS3/SYSV on a 3B2), so I am all for the mighty CLI

That said-- it is really nice to have all of those configurable features. Ideally they should become config options in the game conf file rather than compile-time features, but I understand quite well how big a pain that is.

Yup, we have a ton of customizations that way. All the mysql is in a rhost_mysql.conf, again, the Makefile menu interfaces with it.

The only compile times are those that make huge differences in the code itself, and again is just populated as DEFS's in the custom.defs file. So entirely CLI capable with batch processing. Yay is the UNIX.

Admittedly, a lot of my customizations to MUX were to remove a lot of #ifdefs for obsolete crap.

Take your MUX inc()/dec() option. What's the harm in having that always enabled?

Yea, some of these things we likely will re-visit to change from compile time to just conf parameters, most of it however was due to speed/performance considerations at the time.

[X] 26. SHA512 Passwords

I hope those are still salted?

Absolutely. 10 character randomized seeding per password encryption.
No rainbow table decryption for our baby