All of which we have in abundance, and being that a CPU demands of your typical MUD client and MUD connection are pretty low, most people have the ability have open their favourite email composer, browser and IM software all at once to satisfy their social need.


Which makes sense, for the sake of the MUD and the sake of the IMC, which in turn then serves no true benefit to players of the MUD.


At the time, I was working with a version of tbaMUD, and I stumbled across a IMC2 patch that I thought I'd give a whirl.


All true, and a benefit of partaking in an IMC network. I too enjoy chatting with other owners and developers as I putter along in my MUD, because, as you stated a small MUD can be a lonely place a lot of the time. However, in my case now where I am developing my own custom codebase, to which no 10 minute snippet will exist, would something like this be worth implementing to simply allow me to no longer have to switch MUD tabs in my client to talk to other people. Especially when only myself, and perhaps another staff member or two will be able to use it?

I can't guarantee that as there are about a dozen people using the same server I'm using. As discussed previously I can create a persistent 31 bit random ID for each MUD and send that to the MUD server on connect. That would allow a more secure implementation for MUDs that want security.


The MushLink bot is a primitive MUD client, for me it'd be far easier to script it in TinTin++.

It looks like MushLink works because it connects to MUSH servers with a stock interface, all it does is forward messages using the existing infrastructure. One feature of interest is the remote who. Once an hour the spider could send out an MSSP request, and send an updated who list which would look like: ARACHNOS_WHO :[ :{ $NAME :<name> $HOST :<host> $PORT :<port> $PLAYERS :<players> } :{ etc } :{ etc } ] Biggest problem is that the list could quickly become too big for most MUDs to handle, though I could send each MUD as a separate packet and let the MUDs reassemble it with a time stamp so offline MUDs can be detected.


A special purpose spider would probably work best for this. The minigame could run on one server (or on the spider), with basic interface implementations on other MUDs, and communications handled by the spider. Were you to use a client/server model you'd be forced to stuff all functionality into one program, and you'd probably waste a good amount of time dealing with the person in charge.

The way I'd see it you'd spend a couple of hours implementing MSDP (My own and KaVir's snippets are public domain however) and 15 minutes implementing Arachnos. If you have no love for MSDP it's probably not worth it.

Well that's one of the advantages of the proposal we're discussing - if you're using MSDP, then you won't really need to implement anything more (although in practice you'll probably want to create a separate channel for intermud communication, but that shouldn't even take 10 minutes).


I've already started developing a simple bot, and it should be fairly easy to hack my protocol parser into it, I'll see if I can get a proof-of-concept working this week.


A decent from-scratch MSDP implementation would take more than a couple of hours, particularly if the mud doesn't have a proper state machine for handling negotiation. However my snippet can be added in about 10 minutes, and even if you don't like MSDP (!) it includes other useful goodies. Arachnos will definitely be another notch in its belt though.

So, Scandum and KaVir are happily solving all the technical details. Whatever issues we bring up will be hand-waved away as either trivial or an issue for the individuals muds to deal with. All well and good.

I haven't heard anything from either of them about the social problems, which are both the reason to HAVE an intermud chat system *and* the most difficult issues to solve.

How is your distributed system going to handle individual player bans from individual channels? Who controls a channel? What happens when the mud which created a channel goes belly up? How do you manage name conflicts amongst mud, amongst channels, amongst characters? What kind of protection do you have that prevents me from sending a message to another client that looks like it came from someone else?

I3 and IMC2 address some of these issus, there are plenty more. Since you guys are throwing all that work away and starting over, I'm just curious if you've given any real thought to making an actual USEABLE intermud chat network, as opposed to one that technically works but is inferior to what's already well established?

What's the selling point here? There are already IMC2 and I3 plugins for both LpMUD and DikuMUD codebases, they work with a relatively small amount of fuss and integrate into the existing channel structure. What do we gain from using this system?

Void proceed(int work, int reward) {
  If (work > reward)
     Abort();
}

I was planning to run a spider as well since it'd take me 15 minutes to write one with tt++, though I can drop the effort. Can we figure out a way for the spiders to work together / handle different areas?


We can't all be on the same page. I'm not even sure if me and KaVir are on the same page.

Well mine is just to test the concept out, I want to see what it's like in action. No reason why you can't use tt++ for the final solution.

Alright, here's a basic test spider if you want to save yourself some trouble, and for anyone interested.

I obviously couldn't test it, but it might work out of the box if you load it with #read <filename>, then connect using #session <session name> <host> <port>

#format IAC  %a 255
#format DONT %a 254
#format DO   %a 253
#format WONT %a 252
#format WILL %a 251
#format SB   %a 250
#format SE   %a 240

#format MSDP %a  69

#format VAR  %a  01
#format VAL  %a  02

#format TABLE_OPEN  %a 03
#format TABLE_CLOSE %a 04

#config {debug telnet} {on}

#event {IAC WILL MSDP}
{
        #send {$IAC$DO$MSDP\};

        #nop Should be a persistent 31 bit random number, but for testing this'll work;

        #send {$IAC$SB$MSDP${VAR}ARACHNOS_ID${VAL}123456789$IAC$SE\};

        #send {$IAC$SB$MSDP${VAR}REPORT${VAL}ARACHNOS_DEVEL$IAC$SE\};
}

#event {SESSION CONNECTED}
{
        #var MUD_NAME %0;
        #var MUD_HOST %1;
        #var MUD_PORT %3
}

#event {IAC SB MSDP ARACHNOS_DEVEL}
{
        #format time_stamp %T;

        #var {DEVEL} {%1};

        #showme <118>[DEVEL DEBUG] $DEVEL[MSG_USER] : $DEVEL[MSG_TEXT];

        #var result {};

        #var result $result${VAR}MUD_NAME${VAL}$MUD_NAME;
        #var result $result${VAR}MUD_HOST${VAL}$MUD_HOST;
        #var result $result${VAR}MUD_PORT${VAL}$MUD_PORT;
        #var result $result${VAR}MSG_TIME${VAL}$time_stamp;
        #var result $result${VAR}MSG_USER${VAL}$DEVEL[MSG_USER];
        #var result $result${VAR}MSG_TEXT${VAL}$DEVEL[MSG_TEXT];

        #send {$IAC$SB$MSDP${VAR}ARACHNOS_DEVEL${VAL}${TABLE_OPEN}$result${TABLE_CLOSE}$IAC$SE\}
}
#alias {devel}
{
        #format time_stamp %T;

        #var result {};

        #var result $result${VAR}MUD_NAME${VAL}Arachnos Debugger;
        #var result $result${VAR}MUD_HOST${VAL}idontknow.com;
        #var result $result${VAR}MUD_PORT${VAL}1234;
        #var result $result${VAR}MSG_TIME${VAL}$time_stamp;
        #var result $result${VAR}MSG_USER${VAL}MisterDebug;
        #var result $result${VAR}MSG_TEXT${VAL}%0;

        #send {$IAC$SB$MSDP${VAR}ARACHNOS_DEVEL${VAL}${TABLE_OPEN}$result${TABLE_CLOSE}$IAC$SE\}
}

I went ahead and picked some variable names: MUD_NAME, MUD_HOST, MUD_PORT, MSG_TIME, MSG_USER, and MSG_TEXT. Guess now is the time to discuss changes and additions.

That may be your preference, but it isn't other people's. :smile:

As far as I can see, your spider would only connect to one mud - you could use it to read and write Arachnos messages via MSDP, but I was planning to test the concept by communicating between two separate muds.

My bot now connects to two muds and reads what they send. I'm still working on parsing the data, but that should be fairly straightforward, as it can ignore everything in-band. If it receives an Arachnos message from one mud, it'll send it to the other, using MSDP.

There'll eventually need to be one bot per mud, with each bot connected to both the central chat server and one of the muds. In theory the bots could also use I3/IMC2, allowing MSDP muds to access the existing intermud networks without needing to add any further snippets, and without binding themselves to third-party licences (although using the IMC2 "freedom" snippet would bind the bot to the Diku licence, it wouldn't add any such restrictions to the mud itself).

That script is indeed intended just for debugging. My general idea is for the spider to directly connect to each MUD. Not to have each MUD run a bot that connects to a central server as you'd be back to the same centralization problems that other networks have. I also don't think most MUDs would bother to run a separate program in conjunction.

While at it, my script echoes messages back to the sending server as well, which should obsolete the need to handle local echoing of messages separately.

On the multi-mud subject, looks like all that's required to get the script to do so would be changing:

#send {$IAC$SB$MSDP${VAR}ARACHNOS_DEVEL${VAL}${TABLE_OPEN}$result${TABLE_CLOSE}$IAC$SE\}

to

#all #send {$IAC$SB$MSDP${VAR}ARACHNOS_DEVEL${VAL}${TABLE_OPEN}$result${TABLE_CLOSE}$IAC$SE\}

And connect to two or more MUDs.

I've got msdp command support working in Lola, so I'll probably have an Arachnos capable server up around Sunday.

One thing I'd consider changing would be MSG_TEXT to MSG_BODY.

I've got it working on my end, for now using the following variable set, indentation means the data is nested within the preceding variable:

ARACHNOS_DEVEL
MUD_NAME
MUD_HOST
MUD_PORT
MSG_TIME (unix time stamp)
MSG_USER (name of the player sending the message)
MSG_BODY (used to be MSG_TEXT)

There was discussion about using ARACHNOS_CHAT for a player chat channel, I've not added an MSDP event for it in my implementation, but it'd be easy to do.

For a server list I've got the following:

ARACHNOS_MUDLIST
MUD_NAME
MUD_HOST
MUD_PORT
MUD_UPTIME (retrieved from MSSP)
MUD_UPDATE (time stamp of last MUDLIST update)
MUD_PLAYERS (retrieved from MSSP)

This would make supporting MSSP an additional requirement, but I don't think that'll be a problem. One way of implementing this is to add each ARACHNOS_MUDLIST update to the beginning of a linked list, then remove the duplicate (if any) from the list, and if the list is longer than 100 entries, remove the last entry. That way muds that are down will sink to the bottom. I've set the crawler to update each MUD every 30 minutes, so in theory that should give a fully updated list in 30 minutes. I'll probably update the crawler to handle this better.

I got a tt++ script (v2.00.5 and up) for the spider with above functionality here: http://tintin.sourceforge.net/arachnos/a...

I also got a spider running, so far only connected to my own test server.

I created an infamous green page for Arachnos:

http://tintin.sourceforge.net/msdp/arach...

why green?

Error on your page there on the nav bar. If you click on MCCP it has the title of Mud Server Status Protocol (instead of Mud Client Compression Protocol).

Because it radiates an aura of thoughtful authority?



I've fixed it, thanks.

MTH 1.4 contains all the info to add Arachnos server side for anyone who's interested.

http://www.mudbytes.net/file-2608