Posts made by Chime

@RnMissionRun said in Chime's MOO thread:

Are you familiar with RMOO?
Check out https://github.com/toddsundsted/rmoo

I may need to adapt it a bit for the last six years of emacs changes, but this is... fantastic. Thank you!

@RnMissionRun said in Chime's MOO thread:

WAIFs and dictionaries are different things. A dictionary is a hash map:
A WAIF is a type of "lightweight object".

Last time I'd poked at this, objects were the "normal" way of getting dictionary type behavior-- using properties on some object that is, generally with a _ in front of each key.

This looks much better.

They're quite useful for virtual inventory systems, weapons, clothing, even use them for exits to replace the default MOO $exit object parent.

* supervillain laughter *

That looks magnificent.

If you're serious about working with MOO, I strongly urge you to go to http://www.vmoo.com/en/download/ and download the VMOO client. Once you've installed it, log on to the MOO and type:

Awkwardly, when I first switched to UNIX in 1995 they plunked me down in front of a DECstation 5000/25 with D|I|G|I|T|A|L UNIX and emacs 18. Well, vi was there too, but it was vi, not vim. So I've been an emacs user ever since, and I'm quite comfortable writing complex interactive elisp.

This will enable local editor support on the MOO.

We are in complete agreement that this is a mandatory feature, as well as all of the syntax highlighting, indentation, on-the-fly lint, context-sensitive language/api help, and automated structural editing and refactoring tools.

Preacher, meet choir.

This app works fine on MacOS and LInux under WINE, but you do have to install mfc42 using winetricks or whatever.

I've used emacs on Ultrix, IRIX, Solaris, HP-UX, MacOS X, Windows 9x and NT relatives, and... uh, ITS on PDP-10. Skipped the VAXen, for now. ... I will stick with emacs, for now.

This is all very good info about workflow expectations in existing MOO users though. Thank you.

@Tyche said in Chime's MOO thread:

I have a bunch of old MOO stuff here:
ftp://ftp.sourcery.dyndns.org/archive/servers/tiny/moo/
The oldest code I could ever find was the 1.6.1 version from August 1992.

You do not disappoint! Very nice.

All of the source releases have the RCS comments (from $Log$ entries), so that's not new, but having the 1.6 era tarballs is a nice feature.

It has the RCS comments in it going back to 1990, but there is very little if any Tiny code in there or evidence of Stephen White's hand in it.

He's still in the attribution list, though with the nebulous "portions copyright" bit. I'm not bored enough yet to go token by token looking for similarities with a MUD ancestor yet.

This site has a lot more recent/semi-active links:
http://www.lisdude.com/moo/

Also very helpful; has a good collection and explanation of a lot of the patches out there. The WAIF stuff in particular I'd already pulled out of the SF cvs archive, but having the additional context and link to the author's site is good. Not sure what I want to do with all of those cores, but they might be useful for reference.

Lisdude had a link to wrog's more recent github copy of lambdamoo-- didn't realize that was out there, but now I do. It seems to be a fork of some other random person's git based copy of lambdamoo that wasn't generated from the original cvs repo. Kids these days have no respect for the roots...

Anyway, going to gather up the trees coherently and make a more modern github release for reference. Thank you for archiving those source trees!

@Lithium said in Chime's MOO thread:

@Chime I wouldn't discount the option of coding mux like commands into moo, it'd make it a lot easier for people who are used to that code to jump into the game and get involved. If the commands aren't what people are used to they tend to simply walk away.

Planning to support most MUSH/MUX style commands where possible, yes. This is generally best done in softcode on a moo.

Or make a really solid tutorial so that people can get the information on how to use the code upfront

The goal of this project is that a typical MUSH player will be able to login to MOOs using this server version and core and not need to write any code; everything will mostly just work like they want it to.

Anyone wanting to add new commands will need to do it in the MOO fashion, which is already well documented.

But yes-- I expect documentation and tutorials are a huge part of the work.

@RnMissionRun said in Chime's MOO thread:

I would suggest going with MOO because it's still somewhat popular and lots of people know how to code, build, etc for it. It's also the only one of Cold, Cool and MOO that is still fairly up to date.

This is why we are here!

I would not use the stock server code but rather the HellMOO server, which adds some nice features as well as a dictionary datatype.

I'll have to take a look. I think the WAIF type is similar in utility, but if hellmoo's dictionaries are more robust then by all means.

Stunt might also be a valid choice but I have never been able to get it to work.
GammaMOO might work, also.

Both on the list to examine.

For my own projects I use the HellMOO fork of the server, along with stock LambdaCore. The only real drawback to using MOO is that large games can easily use hundreds of megabytes of RAM and a lot of CPU, making it a poor choice for use on shared servers.

So do MUSHes if you raise the LBUF limits to reasonable values. The Reach frequently hit 300-400MB RAM.

I think the real difference here is that MOO operates exclusively in what MUSH people call "in-memory" mode. MUSHes have been altered many years back to shove values to disk so they can run in very tiny amounts of ram.

While that is certainly an option, virtual memory handling, ram cost, and a variety of factors have changed over the past 25 years. I'll work on memory usage if it becomes a problem, but approaching that first seems like a premature optimization.

Cool is nice but utterly obsolete (it lacks support for for floating point numbers, for example) and lacks a decent starter core. I would not consider it for serious use unless you really, really like the idea of being able to interconnect a bunch of CoolMUDs seamlessly together.

Ew! We like floats. I'm going to need them for my KerbalMOO. (heh!)

The inter-mud connectivity that cool had is really interesting stuff but I'll have to think about how those concepts could be used in a more modern setting. I do see potential for distributed MOO data storage and processing being a useful feature for scale-able cloud-based hosting. And that has to win some horrid buzzword bingo, ew.

Cold is awesome but the server hasn't been updated in more than a decade and can have issues running on 64 bit hardware. Documentation is lacking, you're have to sift though the default core to figure out how everything works. I've used Cold as the basis for several games over the years (none of which ever really took off, sadly). I still have a test server running with a core I've been tinkering with for many years. I can supply you with the address if you're interested in checking it out. The downsides to using Cold include nonexistent documentation and zero support (meaning, you'd better be able to fix any bugs or other issues with the driver yourself).

I may need to do that, but I've got enough things to peek at for the moment. MOO has fantastic documentation, and that's one of its greatest strengths.

Evennia is probably much too bare bones at the moment to consider using it for a game unless you're really keen to do a Python MUD and won't mind investing a lot of time building the tools and infrastructure that would eventually allow you to build a game. At least it's well documented and you can get support from the author/community if you need it.

Again, on the to-do list to take a more detailed peek. I'm not a huge Python fan, but it's better than a lot of choices for that sort of thing.

Regrettably, I became a Perl expert back when that was popular. Python feels clunky, at least until I have to read someone else's Perl-- then Python seems quite nice.

@Seamus said in Chime's MOO thread:

He had most of that. He coded MUSH command syntax into the MOO to make the conversion easier. There were still some rough edges, but they were not mountainous.

That's an option, but frankly I don't see much mushcode worth porting over in that fashion.

@Ashen-Shugar said in Fallout/Wasteland existing code/snippets.:

The only issue this runs across is if you restrict @pemit from players, then objevalling to the enactor breaks because pemit() inherits the @pemit restrictions.

Brilliant idea, but gotta keep in mind games that may restrict commands down.

IIRC, the restricted pemit option you had limited it to targets in the same room if it was running unprivileged. That shouldn't be a barrier here, as you are running a pemit to-the-target AS-the-target, e.g. reach's ooc command:

&cmd_ooc %va=$ooc *:
think setq( b, ooc );
@assert isic( loc( %# ))=
  @pemit %#=msg( h, %qb, This is not an IC area%; just use say/pose/@emit. );
think setq( a, ucstr( objeval( %#, udefault( %#/oocansi, %xc<%xn%xhOOC%xn%xc>%xn ))));
@assert strmatch( stripansi( %qa ), <OOC> )=
  @pemit %#=msg( h, %qb, Your &OOCANSI does not say <OOC>. );
think iter( 0 1 2,
  setq( %i0, delete( %0, 0, %i0 )));
think setq( m,
  strcat( %qa%b%K,
    switch( %0,
      :%b*, %q2,
      :*, %b%q1,
      ;%b*, %b%q2,
      ;*, %q1,
      strcat( %bsays%,%b, chr( 8220 )%0, chr( 8221 ))))); 
think setq( n, strcat( %[, name( %# )%(%#%)%,ooc%]%b ));
think iter( cat( %L, lcon( %L )),
  if( cand( hasflag( %i0, nospoof ), not( strmatch( %i0, %# ))),
    objeval( %i0, pemit( %i0, %qn%qm )), objeval( %#, pemit( %i0, %qm ))))
-

Message in %qm processed for emotes, fake nospoof tag in %qn. Messages never leave the room, so restriction shouldn't matter, but even if someone was crazy enough to implement a softcode channel system (heh!) this method should work for customizing the nospoof output.

...There are probably better ways to approach this problem tho...

@Seamus said in Chime's MOO thread:

Once upon a time there was a moo coder out there that iirc went on to run a Chicago based wod mush. He was pretty fancy with his moo code.

That sounded like the start of a limerick for a bit there....

To be clear: I would love to see a renaissance of urban fantasy mu*s facilitated by a better server environment. I think the game I want to make is more sci-fi type stuff-- but I will be trying very hard to make a modern, mush-user-friendly moocore that will make sheets, chargen, etc. a snap to deploy for most would-be game owners.

But we aren't there yet.

Putting a new thread here to talk about this, as it's come up in various other scattered threads repeatedly...

For a multitude of reasons, a non-zero number of us like MOO and would like to use it or something like it for a non-zero number of things.

For those with no idea what MOO is but eager to add to the thread, please first see MOO on wikipedia.

So, the lambdamoo hardcode. Most linux distributions shipping a copy of it have taken what was on the sf.net project. I did a full clone of their CVS (yes, this shit is old) repo, but found that it was only a repo of work done by the sf people, and stretches back only to 1997, which is rather disappointing. Does anyone have a copy of the original RCS files from the lambdamoo project, as worked on by Pavel Curtis at Xerox PARC (going back to 1992)-- or even more interestingly, the code by Stephen White tracing the lineage from TinyMUD?

It isn't necessary, but the information-archaeologist in me would love to have proper and complete records. @Tyche? I know you've posted in the past about hardcode distribution archives for MOO/CoolMUD/ColdMUD in the past-- But that was long ago, on WORA. What do you have, exactly?

Things I'm working on:

• Further review of Cool/Cold
• Examination of modern python-based games
• Basic packaging of a modern easy-to-build moo with a mush-like interface in supplied softcode core

@Thenomain said in Fallout/Wasteland existing code/snippets.:

TinyMUX doesn't have a 'nospoof' @pemit, so @nspemit --> @pemit will have to do.

And yet I had a variety of code on The Reach @pemiting without nospoof tags, e.g. the posebreak stuff.

Hint: just run the pemit as the target (see objeval) and no tags are printed.

@Thenomain said in Code Teachers?:

I want to cut strmatch( x, y ) out and replace it with u( f.match.things, x, y ). In TextWrangler, I get inside the parens, type cmd-b ('balance and select') then shift-cmd-backarrow ('select previous word') then delete. Then I start typing. Done. Easy. Done.

It wouldn't be hard to do this in emacs, though the terminology and conventions tend to be different.

In particular, if you're already using smartparens (or Riastradh's excellent paredit...), there's a function sp-backward-up-sexp:

Move backward out of one level of parentheses.

With ARG, do this that many times. A negative argument means move forward but still to a less deep spot.
If called interactively and sp-navigate-reindent-after-up is enabled for current major-mode, remove the whitespace between
beginning of the expression and the first "thing" inside the expression.

Examples:

(foo (bar baz) quux| blab) -> |(foo (bar baz) quux blab)

(foo (bar |baz) quux blab) -> |(foo (bar baz) quux blab) ;; 2

(                  
​    foo |bar baz)
                           -> |(foo bar baz)

Combine that with backward-word (M-b) and/or various delete bits and you've got basically what you have above. In particular, something like:

;;; replace-mush-function.el --- because Thenomain wanted it

;; Copyrights and module metadata should go here.  Meh.  Chime wrote
;; this.

(require 'smartparens)

;;;###autoload
(defun replace-mush-function ()
  "Delete the enclosing parenthesized list and the preceeding word.

This function uses `sp-backward-up-sexp' and friends from
`smartparens-mode'; as a result it can and will reformat text
across expanses of lines.  Be wary."
  (interactive "*")
  (when (looking-at "(") (forward-char))
  (sp-backward-up-sexp)
  (let ((sp-no-reindent-after-kill-modes (list major-mode)))
    (sp-kill-sexp))
  (backward-word)
  (kill-word 1))

(global-set-key (kbd "C-c r") 'replace-mush-function)

(provide 'replace-mush-function)

;;; replace-mush-function.el ends here

nb. this markdown code syntax highlighter has a truly rubbish selection of modes.

But anyway! After loading the above I can do all of what you want by typing C-c r (control-c, then r). The dynamic let chicanery could be skipped if we made a proper major-mode for mushcode.

Really though I'd rather do that for MOO and continue working on resurrecting that lovable beast...

@WTFE said in Flights 'n Tights MUX:

And women, @silentsophia. I rarely feel embarrassed for my gender. Comic book shops have always made me consider just getting a straight razor and cutting off the offending bits as an apology for the contents of the shop.

Once upon a time I worked in a comic book store. Never again. Never. I would rather live in a cardboard box. They exude a lingering miasma of entitled, willful ignorance. Well, that and the paychecks started bouncing and they never sent out a W2. (yes, yes, any sufficiently advanced incompetence is indistinguishable from malice...)

@Thenomain said in Flights 'n Tights MUX:

I, myself, am optimistic about using those bits again sometime.

* Wicked cackling intensifies *

@Thenomain said in Flights 'n Tights MUX:

Is that exclusionary? Or is it reasonable theme-enforcement and defending the game so that it can continue to be a game?

Seems like theme-enforcement (or more politely, focus), to me.

Games centered in a city tend to require play to largely be in that city. Games focused around mortals tend to require mortals.

A collaborative storytelling project exploring the intricate dynamics of masculine power-plays and the many variations of male-love within the context of a super-hero settings could be quite a reasonable and compelling goal.

As @surreality mentioned, a lot of us don't tend to play male characters. I can do it, but I don't generally find it compelling. As a result, while I respect the coherence and unified purpose of their dream, I probably wouldn't play there.

I think the downvotes to the original poster (@Hushicho) come from the idea that it's said to be a perfectly open-minded game about sexuality, but the "traditional" gender normative ("cis") tropes are either secretly or openly shunned.

Having hosted the game for years, well, I can assert that @Hushicho is a really nice person. Glad to see them make it to the forum, and it's a damn shame people decided to downvote what they don't understand.

That said, I've never logged in.

@somasatori said in Loki @ HM:

I'm looking for Loki to ask him a few questions about some HM-specific content I'd like to use and for which I'd like permission. If anyone can throw me a note as to where I might find him, or if he reads the boards, send me a PM. Thanks!

Really though, it depends on the content. Are we talking grid-features, descs, code, algorithms, design motifs, etc.? Lots of different people involved in that game.

I messaged him on that thing about stuff.

@Arkandel said in Mud Hosting, for 0 budget?:

@DnvnQuinn Even so - for running a MU* the hardware requirements are pretty lax. Running Linux might be your bottleneck though - I don't know if you can run it on Windows, never tried.

Mux runs on windows; gotta use Brazil's version though.

No, it isn't really a legit means of running a game for more than early development purposes, but it's better than nothing. I guess.

@Tat said in How should we (as a community) handle MediaWiki:

I'm personally less interested in the 'easy to get up and running the way you want' than I am the 'easy to use once it is' - I'm happy to put in a lot of work at the get-go to get a wiki that doesn't require much upkeep or handholding on my part. I get that not everyone thinks this way, though.

Well yes. Ultimately the setup should be to ask the owner a few questions in some web form, have them push a button, and bam-- a wiki-- with zero interaction on my part.

For hosting providers like me

I don't have much to say on this one - we simply went from paying for space for a webpage to paying for space for a wiki. I installed it (a process I found absurdly easy) and customized it (definitely a lot of work to get to the level we're at now, though I keep stealing things from old wikis at this point).

I'm definitely curious about where your frustration points are.

Heh. Well-- you pointed out it'd be nice for these things to be hands-off. They aren't. Not remotely.

Game owners like to have these things-- wiki, forum, etc. and they never conceive of the idea that they should keep them up to date and patched from vulnerabilities.

PHP and virtually everything written in it has an atrocious track-record on the security side. So do many other things, and I don't really see a lot of good wiki alternatives that don't use PHP, but that developer ecosystem is particularly bad and has been so since its creation.

Individual game owners do not keep things up to date, and never will. Do they have the permissions? Yes. Can they? No. It isn't hard, but they just won't do it.

That leaves it to me to do when necessary, or to pull sites down. Upgrading 30 different wikis with incompatible config files and breakage points manually is kinda hellish, especially when people then feel entitled to blame me because their shit broke when I updated it.

That's not going to work. It can't scale, and I can't waste that much time on stupid php crap. The discussion here was to get a better sense of how all these wikis (within mechanipus and elsewhere) are being used, so that when I have a new mediawiki deployment and management feature it will do what people need it to do. A list of Extensions-- which many people have provided-- helps quite a bit.

End goal is to have a single mw install with a tiny php stub in each user's site that sets it up to run as their wiki and holds their config. There will be only one copy of the main Extensions list, one copy of all the normal mw source and language files, etc. That way, when they send out yet another warning email saying oops-we-blew-it-again, I can trivially update that one install.

If what you're aiming for is a game-in-a-box that includes a mediawiki install, I'd probably suggest a basic install with a few additional extensions up and running, and a depository somewhere of easy-to-tweak templates for commonly used things like character pages or logs.

Yep. Both for use for games I choose to host and usable as a package for people rolling their own somewhere, or for hosting companies that want to leverage these ideas for-profit. Any and all of those are fine.

The extensions I'd call must-haves are

• Arrays

Hm! Yes, that looks interesting.

• DPL (IF not using Semantic Wiki - I'd consider Semantic advanced MediaWiki'ing)

DPL, yes, though I've been sold on Semantic.

• Parser Functions
• WikiEditor
• Input Box

Yep.

• Confirm Edit with QuestyCaptcha plug-in

I don't particularly like captchas, but automated spam deterrents are necessary, so this is probably essential. Question based ones are certainly better than the "identify something like a word in this picture of abstract noise."

If you're being really nice, I'd also include a skin that isn't the god-awful Monobook.

Vector is included in the default install, for a while now. Most new wikis default to that. Anything using Monobook is horrendously antique.

I'm not sure if this really gets at what you're asking - these are the reasons we stick with MediaWiki and why I like it, anyway.

Thank you. This is wonderful and useful information.

@faraday said in How should we (as a community) handle MediaWiki:

@Chime The Wikidot API is somewhat limited and requires you to have a Pro account (currently about $50/year).

They clearly have more business sense than I do. Alrighty.

For Evennia, making a MediaWiki integration might make more sense, since it's geared more towards advanced users. But since Ares is intended to be a "MUSH In a Box" turnkey installation, MW just isn't suitable. It's too much of a PITA to set up and configure and maintain (in my experience).

I'm going to need to do my homework and look at Ares and Evennia in more detail, it sounds like.

@surreality said in How should we (as a community) handle MediaWiki:

I strongly recommend looking closely at Semantic Mediawiki specifically.

Thank you for reminding me. I peeked at it years ago and it seemed like a great direction to go but wasn't really fully implemented at the time. Might be exactly what I'd want to get the most out of MediaWiki...

On the user/wiki-admin side, it allows for a lot of things that aren't standard in the box with mediawiki, and to the best of my knowledge are not in wikidot at all either.

Yeah, even my Mechanipus mw setup had a bunch of extensions installed (some custom) and a lot of config tweaks.

Forms are a big one for a number of reasons.

Yes! Yesyesyes! I'm very glad you see this.

I suspect there are a lot of important data-entry things with forms that can be useful even for games with no automatic integration; i.e. DPL views and the like that pull form-submitted data to generate code to paste into the MUSH.

Direct is better, but even manual stuff can be a big timesaver.

They make things much easier on non-wiki-savvy users, for one; it's possible for a user to create a page without a single shred of code know-how with them, and templates can be made fairly easily for just about anything the game needs. (I've been working up some basic ones for things like grid locations, player pages, etc. similar to the ones on BITN's wiki, and when the generic versions are ready I want to have them up where they can be grabbed and shared.) It's possible to enter specific instructions for every step of the process, for every input on the form, with as much or as little information as players or staff may need to ensure the information is correct, useful. It helps ensure it's easy to understand what to do, how to do it, and why it's needed (or even if it's needed or optional). And this is all without needing to know a single thing about wiki code on the player (or data entry staffer) end.

I've seen a large proliferation of copy-pasted DPL queries that don't make much sense, because people tried to move things between games. It's a good idea though, and making that work safely and cleanly in a game-independent fashion as a separate project (think Sandbox Globals Project, but for MediaWikis serving MUSH communities) would probably be a good idea.

The extra bonus for forms is that it's possible to set up lists of default allowed values that will appear in the template; while that sounds little, it can be big for things that the MUX expects to appear in a very specific way. Whether something is 'Circle of the Crone' or 'The Circle of the Crone' can make a big difference code-wise, for instance; if it's set with a drop-down rather than entered manually, it's always going to be consistent and there's no need to remember how it's supposed to be done. (Because nobody always remembers. It always gets screwed up somewhere, some time. )

Yep.

I am also not sure if wikidot uses/allows the use of DPL or not at all. DPL is extremely useful to create auto-populating listings throughout the wiki that massively reduce the need for constant direct human maintenance.

DPL is fairly powerful and critically useful. It's also really ugly and difficult to explain to people. Sanding down those corners and making it accessible in standardized fashion to non-technical game owners will be important.

@faraday said in How should we (as a community) handle MediaWiki:

I haven't used MediaWiki for a MUSH game since, like, 2007. Wikidot has everything I need, and it's free, and I don't have to screw around with hosting options for it. With creative use of templates, includes and tags, you can do auto-generated RP log lists, faction pages, tutorial navigation, and everything else I've ever wanted to do.

This is a good point. (And what I'd been wanting people to do for a while, but there was considerable push-back, hence this thread...)

The only place that Mediawiki beats it, IMHO, is MUSH-to-wiki integration. As @Thenomain mentioned in another thread, you can use the SQL output from MUSH to write stuff directly into MW's tables, effectively adding things through a back door. It's kind of a hack, but at least it works. You can't do that with wikidot, but between in-game "here copy/paste this" commands and fill-in-the-blank templates, it's not been a big deal. YMMV.

ahahaha

Okay, I was the one who wrote that stuff, e.g. for The Reach and most other places using it. So I guess it's my fault I'm stuck with this thing. Fair enough.

It works well enough, but as you say-- it's an ugly hack. MediaWiki should be able to change their internal database structure without warning, and that would break all tools trying to do direct reads/writes of its database.

It's far better to manipulate MediaWiki through their published API, but MUX at least will need some hardcode changes to be able to do this sanely.

Note that WikiDot can do the same thing. If we can all agree that we should be doing this via the API and arrange for that infrastructure to work on the MUSH side, then:

• We can have a MU wiki lib (with version for different MU types able to do RPC calls of various sorts); MUSH is the primary relevant one here, but hey I can probably do MOO too, etc.
• That lib can have connectors for talking to MediaWiki, WikiDot, and other alternatives in a read/write fashion.
• MU applications such as WikiNewsHelp, ticketing systems, bboards, etc. can then target that lib, allowing game owners to pick and choose apps and backend hosting independently.
• That same lib could use local database edits to support existing systems that want to continue doing my particular dark witchery with a local mediawiki.

WikiDot and MediaWiki have diverged considerably and use different syntaxes, but I suspect most of the same concerns apply as far as player and owner user-cases.

I've been very annoyed at MW for quite a while now, but I've realized that it isn't something I'm going to be able to discard and still offer a useful hosting service, really.

So, let's talk about what things are needed:

• For game owners
• For a game's power users and/or staffers
• For a typical game player wiki user
• For hosting providers like me
• For game owner-and-hoster-types

I've worn a variety of these hats and can talk especially about my concerns from the hosting side and potential solutions, and what they might mean for game owners. I suspect most of my options and their effects will be completely invisible from most people, but here's a good chance to speak up about what things make mediawiki a must-have feature for YOU.

@surreality, @ixokai, and others who have nudged me to consider mediawiki still, please add your two cents. Use-cases, features, things that can be done right, things that can be wrong, etc. are all very relevant to my interests in this thread.

Other hosting providers? Mechanipus isn't aiming to be competition in this area-- I specifically believe this isn't a viable business model, so I'm gearing this toward establishing the best way to do it as a community so I can put together some comprehensive game-in-a-box options including MU and wiki and forum and such-- either for use by aspiring game-owners; overworked and frantic code staff; naive but powerfully eager would-be hosters; or myself, who is often in all of those categories.

Things like my wikinewshelp bridge and the like-- we can do this and do it better, and do it more portably.

Woot! Steamy can be good.

Steamy can be very good.

Oh. Uh. A URL. You kids and your web thing.

https://www.patreon.com/lashtear

I feel so awkward putting something like this up-- but here it is. Very no-frills and barebones at the moment, but for those of you who would like to nudge my tip jar, I now have a Patreon account thing set up.

I can post specific goals and things there if people want me to do that, but for the meantime it's a Help-Chime-cover-hosting-and-coffee type of thing.

Please feel under absolutely no obligation of any sort-- I'm not deathly ill or destitute, but I have the business sense of an octopus in a peanut butter jar. This helps people help me, and gives you a handy way to nicely prod me toward improving MU* things we share interests in. One-time and recurring payments of any sort are all quite welcome.

Things I've been doing (and will continue, anyway):

• Mechanipus MUSH hosting, in its various forms
• Work on TinyMUX for various features/feeps/improvements
• Mushcode here and there for certain games

Things I can be nudged into working on more (words are worth as much as money, but money does give me more time to spend on this):

• Working on MOO hard/soft code to get that into a usable state for modern MUSHers.
• Writing targeted tutorials (probably here) for everyone to read on certain topics. Not sure about the audience yet, but devising training materials for esoterically technical stuff for people with no time to understand is something I do for work already...
• Wrapping up the packaging details and documentation on my TinyMUX changes (as seen on github) into a formal release of some sort.
• Porting specific features between MUSH versions.
• Implementing specific MUSH features. (JSON manipulators, xml-rpc/json-rpc hooks in both directions, variable buffer size (VBUFs instead of LBUFs, more and better regexp support, built-in mushcode prettyprinting and debugging features, etc.)
• Helping create a better framework for mush-mediawiki integration
• Devising a better mediawiki hosting setup so I don't tear my hair out and other people more interested in doing actual large-scale-hosting-as-a-business can deploy it.

Existing Mechanipus customers!

• You don't need to do anything. Really. It's not going away, and I'm not likely to ever manage to turn Mechanipus into a viable business.
• This is just if you want to help out in this way.
• It is very much appreciated though, especially if you need a lot of help with fixing mush issues.
• This is not payment-for or a promise of support, but it does keep me less burned-out and more able to cover the Mechanipus hosting costs.