[Kylotan]

I'm working on a new client, which I hope will mark a significant step forward for muds when it's done. But I could do with a little feedback on the features people need - in particular, on open extensions to Telnet that some games are using.

Which of the following are in (common) use?

MXP - mud extension protocol
MCP - mud client protocol
MCCP - mud client compression protocol
ZMP - zenith mud protocol
MSP - mud sound protocol
... - any others I've missed?
... - anything useful these don't cover?

ZMP seems to have the best implementation, but MXP seems to be the most widely used. Any information or opinions appreciated.

[Aeran]

Originally Posted by (Kylotan @ Mar. 19 2007,09:51) I'm working on a new client, which I hope will mark a significant step forward for muds when it's done. But I could do with a little feedback on the features people need - in particular, on open extensions to Telnet that some games are using. Which of the following are in (common) use? MXP - mud extension protocol MCP - mud client protocol MCCP - mud client compression protocol ZMP - zenith mud protocol MSP - mud sound protocol ... - any others I've missed? ... - anything useful these don't cover? ZMP seems to have the best implementation, but MXP seems to be the most widely used. Any information or opinions appreciated.

If you implement MXP then you also want to implement MCCP to reduce amount of content that needs to be sent to client. Also MSP is supported by MXP.

[Kylotan]

To be honest I'm not that bothered about MCCP. Only when I had to use a 2400 baud modem have I ever found the amount of data sent by a mud to exceed my bandwidth.

[KaVir]

Originally Posted by (Kylotan @ Mar. 19 2007,9:15) To be honest I'm not that bothered about MCCP. Only when I had to use a 2400 baud modem have I ever found the amount of data sent by a mud to exceed my bandwidth.

Are you planning to market your client directly to the players, or are you hoping that muds will recommend your client to their players as well?

If the latter, you might want to consider that some muds pay based on the amount of bandwidth they use, and therefore might be less inclined to promote your client if it increases their hosting fees compared to other clients that do support MCCP. Even if the additional cost is neglegable, the very fact that it could increase their hosting costs at all may reduce their inclination to promote your product to their players.

[Kylotan]

I expect that even of the muds that do pay for bandwidth, few of them implement MCCP. If anybody has any evidence rather than conjecture to suggest otherwise, I'd like to see it. In an ideal world I'd implement each of these protocols, but this isn't an ideal world and I don't have infinite time.

[KaVir]

Originally Posted by (Kylotan @ Mar. 20 2007,11:33) I expect that even of the muds that do pay for bandwidth, few of them implement MCCP. If anybody has any evidence rather than conjecture to suggest otherwise, I'd like to see it.

TMC has a search option for 'MCCP', and lists 252 muds, including several of the larger ones.

[Aeran]

Originally Posted by (Kylotan @ Mar. 20 2007,05:33) I expect that even of the muds that do pay for bandwidth, few of them implement MCCP. If anybody has any evidence rather than conjecture to suggest otherwise, I'd like to see it. In an ideal world I'd implement each of these protocols, but this isn't an ideal world and I don't have infinite time.

Implementing MXP compared to MCCP is much tougher. Usually you just use an already made compression library like zLib. So for an experienced programmer it requires maybe 30-60 minutes to add support for MCCP.

Some MUDs like Aardwolf encourages people to use compression by giving bonus experience points if it is enabled. So few serious players there would use a client that doesn't support MCCP.

[Kylotan]

Ok, now we're getting somewhere. That seems to be about 1 in 6, more than MXP and MSP combined. Still, it's a low priority to me at the moment. Implementing MCCP (or indeed any such protocol) on the client side will actually be non-trivial for me, so given that it imparts little actual change to the user experience it's not going to take precedence. I'm biased more towards things that affect the interface at the moment.

[shadowfyr]

Yeah. MXP implimentation has issues. Not the least of which being a) its hard to make a window that supports HTML type elements, like pictures, but still supports text positioning. The client I use didn't bother supporting *either*, since both where a pain to do. and b) if you follow specs, the muds might not, because sadly, zMud *doesn't* follow specs. At least with dealing with the translation of < and > to &lt and &gt. This causes a major pain if you decide to impliment error checking or capture of MXP tags. How do you tell if the stuff between < and > was *supposed* to be a tag, but something it wrong with it, or its just text, especially if the mud uses its own extensions to the protocol, which should logically be ignored, or its an element that is being sent in the tag? Simple, you can't. So you have two choices, a) delete the presumed tag and generate an error response through what ever system you have set up for that, or b) display it anyway, as though it was &ltblah&gt, which the specifications clearly indicate is actually wrong.

Nick Gammon, the creator of Mushclient and Zugg, who makes zMud have had a long conversation about this issue, which left off with Zugg saying, "Yeah, its probably a good idea to make sure everyone knows exactly what the standard behaviour *should* be in such cases.", then not doing anything at all to make the specifications clear about it, or changing zMud... The result is that *some* muds incorrectly impliment conversion, and in clients that treat bad or possible bad tags as errors, not plain text, those muds don't display right. Its just like HTML in IE vs. everyone else. Lets not follow a defined standard, lets just let the client *guess* what you really intended to have happen and hope the result isn't too screwed up in which ever browser you use... That worked so well for HTML after all that no browser in existence can or does display the test pages from the official specs properly. lol

Anyway. You need to be careful of these little annoyances. And in this case, doing it in a way that is technically correct will get you yelled at by mud developers, who are not following spec, but insist that just because everyone there uses zMud and zMud lets you funnel the bad parts into the box with the good ones, there is no good reason for "them" to fix the fact that you're being shipped a box of broken parts. Its quite annoying trying to talk to those people.

[Kylotan]

The rendering stuff shouldn't be too difficult for me, so that's ok.

Anybody got any stats, or even just vague observations, on which aspects of MXP are in common use? I'm probably going to try and cover the trivial text formatting and inline images first, followed by the sound and music tags (along with an MSP implementation).

[scandum]

Originally Posted by (Kylotan @ Mar. 19 2007,09:51) I'm working on a new client, which I hope will mark a significant step forward for muds when it's done. But I could do with a little feedback on the features people need - in particular, on open extensions to Telnet that some games are using.

VT100 support is always nice, though seemingly it's too difficult for most mud client developers to implement.

[shadowfyr]

Well, I am hardly an expert on what is in common use. The first few places I tried that had MXP used only one feature - the ability to set up clickable links for commands. They didn't even use the extended colors, but stuck with ANSI. It looked ugly with all the underlines for the links, the color scheme was horrible for the rooms, they had silly things like coloring a flower red, when the description said it was violet, since of course it wouldn't make sense to.... I don't know, *use* the MXP color code for violet? Not sure if they used the image support, since I ran away screaming after about five minutes. lol

But seriously, I get the sense that most of the stuff that gets supported is the simpler, but fundamentally lamer, features, like text links. The rest is either completely ignored to maintain general compatibility with older ANSI clients (why I have no clue...). Some do specifically use sound and images though. Its going to vary a lot from mud to mud. Some will use images and sound, some will only support text links, a very few probably use what I would have thought to be the most useful and least visually invasive (and I mean even *in comparison* to the high contrast ANSI they use instead) color system. I mean, which would you rather look at, a set of soft, well blended, colors, like 2-3 shades of forest green for the details in a druid guild, or some combination of clashing colors in ANSI that will burn your eyeballs out at 2 AM and do nothing to enhance the sense of where you are? Just saying...

Still, as I said, I am hardly an expert on what people "are" using. But I have been told by more than a few people that there is a fear, hatred or just plain disinterest in even trying to use color support.

[shadowfyr]

Originally Posted by (scandum @ Mar. 21 2007,6:17) VT100 support is always nice, though seemingly it's too difficult for most mud client developers to implement.

VT100, like most of the VT class protocols is simply ANSI with a few things stripped out (or rather ANSI is VT100 with things added). Technically, if a client supports ANSI, it should also, when asked, inform the server that yes, it does also support VT100. The problem is usually that ANSI support isn't always 100% complete in clients either, so neither actually works as its supposed to. However, unlike ANSI, VT100 users tend to "expect" all those codes to do something.

Believe me, I have been using clients with ANSI and VT100 in them since all the way back when BBSs where the rage. ANSI should simply extend VT100, not be completely different, but about 5%? of the codes in both are "never" used on most muds, so its become all too common for people to take their client specifications from the muds implimentation, not from the actual official specifications for the protocols, which is why people think that ANSI doesn't support VT100 functions. The later is usually taken from implimentations that do support those functions, but usually still not from the spec sheets. Over the last year or so the client I use has had to add in specifications for at least 4-5 things that where in the specs, but not supported, because they are not common to all muds and so the developer didn't think he "needed" them.

[Aeran]

Originally Posted by (shadowfyr @ Mar. 21 2007,4:17) Yeah. MXP implimentation has issues. Not the least of which being a) its hard to make a window that supports HTML type elements, like pictures, but still supports text positioning. The client I use didn't bother supporting *either*, since both where a pain to do. and b) if you follow specs, the muds might not, because sadly, zMud *doesn't* follow specs.

You might want to post to the zMUD Developers forum on www.zuggsoft.com and explain what you find to be problematic with MXP. Keep in mind that zMUD is no longer updated. Instead Zuggsoft is developing a new more modern MUD client, cMUD. So now is definitely a good time to post suggestions.

[scandum]

Originally Posted by (shadowfyr @ Mar. 22 2007,2:57) VT100, like most of the VT class protocols is simply ANSI with a few things stripped out (or rather ANSI is VT100 with things added). Technically, if a client supports ANSI, it should also, when asked, inform the server that yes, it does also support VT100. The problem is usually that ANSI support isn't always 100% complete in clients either, so neither actually works as its supposed to. However, unlike ANSI, VT100 users tend to "expect" all those codes to do something.

Some mud and client developers are trying to turn VT100 into a meaningless term as well. It's easier to redefine the meaning of a protocol and claiming you support it than actually implementing it.

The closest thing to a standard nowadays is the linux terminal emulation standard:

http://www.squarebox.co.uk/cgi-squar...onsole_codes.4

Compatibility is easiest to test with applications like Midnight commander.

[shadowfyr]

Originally Posted by (Aeran @ Mar. 23 2007,8:03) Originally Posted by (shadowfyr @ Mar. 21 2007,4:17) Yeah. MXP implimentation has issues. Not the least of which being a) its hard to make a window that supports HTML type elements, like pictures, but still supports text positioning. The client I use didn't bother supporting *either*, since both where a pain to do. and b) if you follow specs, the muds might not, because sadly, zMud *doesn't* follow specs. You might want to post to the zMUD Developers forum on www.zuggsoft.com and explain what you find to be problematic with MXP. Keep in mind that zMUD is no longer updated. Instead Zuggsoft is developing a new more modern MUD client, cMUD. So now is definitely a good time to post suggestions.

Been there, done that. Like I said, this discussion has gone on between Zugg and Nick Gammon, over this already. Mushclient is Nick's client and while its designed to only support scrolled text (i.e., no text positioning) and doesn't allow things like inline images, it takes the literal interpretation of the MXP spec and assumes that something like <A Scary Road> **should** be an error, so won't display it, but instead attempts to generate an error response through the script systems callbacks for MXP tags. Nick's argument, and I tend to agree with him, is that a) without clearer specification, its entirely up to the developer if they fall through or not and display and b) it really doesn't make any sense to do it that way though, since something like <img="abc'> would also pass through, when it should, in a client that supports debug features, generate an error, instead of displaying the invalid data.

I tend to agree. How do you debug MXP tags using script callbacks if 90% of the "tags" are plain text? You can't, unless you either don't allow debugging, or you generate an error for "every" apparent case. If your mud used <> for room titles, but didn't escape them properly, then trying to debug MXP on it would produce an error **every** room. Its just absurd, even if the display behavour is useful. But adding my input to the argument isn't likely change things.

[Kylotan]

Yes, having looked into it tonight, MXP is just a completely unwieldy protocol to implement. MCCP simply wraps everything else, ZMP works with subnegotiation data, and both MSP and MCP only handle whole lines, all of which fit nicely alongside the telnet/ansi handling. Unfortunately MXP seems to want to work inline, across arbitrary amounts of data, with several different state combinations, and little guidance on how to handle tags that don't parse correctly.

I mean, parsing a line like "<!ELEMENT RName '<FONT COLOR=Red><B>' FLAG="RoomName">" is pretty horrific. That would be invalid XML, for good reason.

It's tempting to leave support for MXP out. At least it doesn't seem valid to stretch a tag across a new line so it might be ok to process it in the per-line handler.

[Kylotan]

Actually, this raises another interesting question. Sometimes you get sent data without a newline, such as a prompt. You need to display that verbatim on the screen before you receive a newline, because that newline may not be forthcoming. On the other hand, protocols like MSP and MXP work best when handled a whole line at a time, but that means withholding the display of the line until you get a newline. MSP you can at least spot by the "!!" prefix to the line, but with MXP, I suppose it's guesswork.

Obviously you can get around this by assuming that the MUD sends data in contiguous blocks and having some sort of hacky state that waits for a newline and, if it hasn't received it within a certain length of time, assumes it's a prompt. But that's just plain wrong, really.

Ouch. I wish people had given their extension protocols a bit more thought.

[Aeran]

Originally Posted by (Kylotan @ Mar. 24 2007,6:23) Obviously you can get around this by assuming that the MUD sends data in contiguous blocks and having some sort of hacky state that waits for a newline and, if it hasn't received it within a certain length of time, assumes it's a prompt. But that's just plain wrong, really. Ouch. I wish people had given their extension protocols a bit more thought.

I think you can actually write out the text as soon as you have fully parsed it. What line tags are about is security. Usually you have a security level for the entire line, and as soon as a new line starts it reverts back to default security.

MUDs should really use </> entities for their prompts to make it clear that it isn't a tag. So it isn't really an issue with MXP, but an issue of poor implementation on MUDs.

Something that needs to be kept in mind here is that zMUD is quite good at error recovery. It will sometimes accept sloppy syntax of MXP and try, to its best efforts, make an acceptable parse of it. The bad thing about this is that MUDs who test their implementation towards zMUD might not detect obvious errors that dont quite follow the standard.

[Kylotan]

The problem is that 'fully parsed' is a non-trivial state to spot, especially given that the parsing has to be done on the same level as all the telnet and ANSI parsing. When I spot a '<' character in a mode that allows MXP tags, I need to enter a 'might be an MXP tag' state, start buffering text, and can only emit that text once I have parsed a complete tag, which is non-trivial.

The line modes aren't the issue here.

It's ok saying MUD's 'should' use those entitles, but it's quite clear from several MXP examples on the spec page that they don't have to - look at the 'start' and 'end' entity examples - and that open and closed brackets take on different meaning depending on their position, which makes parsing harder. Unfortunately this also no means that no complying client can assume that such brackets will be sent as entities. That's an issue with MXP. This means I can't just search for a closing bracket to terminate a tag, as I could in well-formed XML, hence the 'non-trivial' comment above.

And this means that if someone sends a prompt in open or secure mode like: "<hp 50 mv 150]" then your client has to make a guess as to whether that's an MXP tag that you have to wait to parse (as there is still a bit missing), or normal data to output to the MUD. Yes, while in your 'might be MXP' state you can keep checking the buffer and spot that 'hp' isn't a valid tag, but then do you emit the text, or do you report an invalid tag? And what if the user set part of a valid MXP tag in their prompt?

In fact, the whole protocol is a complete mess. Unclosed tags get closed at the end of the line... unless they were sent in secure mode... and who knows whether you close them or not when open mode is locked across multiple lines since one sentence suggests you do and one suggests you don't. It's almost a joke.

[shadowfyr]

Originally Posted by (Kylotan @ Mar. 24 2007,6:23) Actually, this raises another interesting question. Sometimes you get sent data without a newline, such as a prompt.

Umm.. ff f9, also known as IAC EOR/GA.

Its a go-ahead code sent by some muds, and apparently implimented in the TMI-2 mudmail editor, though not on prompts... Some muds support it, others don't. Mushclient has a feature you can turn on for, "Convert IAC EOR/GA to newline.", which allows prompts to function as though they actually had a /n in them, but it only works *if* the prompt has IAC EOR/GA at its end. In any case, if the mud sends and the client recognized this, then its trivial to determine if the line is a prompt or not.

But yeah, lots of screwy stuff has been added to Mushclient to get around this stuff, including the fact that while a line will "display" as its recieved (most never exceed the packet size), triggers that attempt to look at the line and figure out what is going on only fire "after" the newline, hence converting the IAC EOR/GA to a newline to make the prompt trigger immediately. If you can't, then you get something like this in script:

[code] OnPluginPacketRecieved () {
if stored packet then
retrieve packet
add new packet to old packet
onpluginpacketrecieved = false
exit function;

'do some regular expression checking.
if complete prompt then
do some stuff to it and put in changed_line
world.simulate changed_line
else if no newline
store packet
onpluginpacketrecieved = false
else
on pluginpacketrecieved = true ' Let the client handle it.
}[/quote]

You can do some crazy things with Mushclient, some of it just to work around silly BS like having no control over what the mud is actually sending you, substituting words and things into the packet (since you can't do that after a line already exists and a newline has scrolled it), etc. Substitution is a bit easier in some, but most of those use some other sort of system to handle triggers, like maybe keeping a list of triggers that it appears *may* match the line, and throwing out the ones that don't as more data arrives?? Who knows...

But yeah, the MXP spec is rather screwy in some places.. Though, in the case of that element thing, what is means is that a line containing the element will substitute the
[code] "<FONT COLOR=Red><B>"[/quote]

part for it, so the code you get is like:

[code] RName My Big Room<\b>

<FONT COLOR=Red><B>My Big Room<\b>[/quote]

XML includes a way to add element replacement like that as well, but what people forget is that this isn't XML, its HTML with some goofy things tacked on, and in the spirit of HTML the behaviour of when and if certain attributes get terminated differs based on *what* those things are. Something like a color, one would presume, would continue to be present until changed, other things are line by line based. Unfortunately, like HTML, zMud liked to try to guess what was intended when tags where mangled. A condition that has resulted, in the browser world, in 3-4 different clients, none of which actually correctly follow the W3C specs or can display their test page, and where the page design standards end up instead being set by the quircks and idiocies of the most popular browser.

[Kylotan]

I don't think anybody here is forgetting that MXP isn't XML, just lamenting the fact that Zugg knew of XML's existence and yet still chose to ignore some of the most important parts, before then writing an inconsistent spec to describe his creation.

My current plan is to buffer data as it comes in, and flush it after every new line, every ANSI sequence, and the end of every block of data read from the network. The last one isn't technically correct but is necessary since few muds I'm aware of will send a Go-Ahead for their prompts by default. I'll then attempt to process MXP tags in the buffer before committing the results to the output window.

Or maybe I'll just abandon MXP support altogether if that doesn't work out well enough! ZMP is easier to implement and to extend to cover everything that MXP does.

It's not one of the protocols you listed, but I think it'd be nice to see multilingual support in clients. If I copy some Chinese characters from another program, and paste them into the client, I ought to be able to transmit them to the MUD-- whether or not the MUD accepts them, is up to the server, of course. Though I dunno whether this is really relevant to any present MUDs, it's something to look toward as we move futureward. I'm happy to hear you are working on a client I'm sorta guilty, since I'm the only person (I think) to still own the gmud sourcecode, but I'm too busy/lazy to work on it.

[Kylotan]

The intention is for my client to handle UTF-8 data from the server - personally I'd love to be able to use Unicode so I can send more exotic-looking text, using Gaelic or Old English characters for example. Obviously you will need a compatible font.

I'm not sure about sending the data to the MUD, though I suppose that as long as the text control I use supports UTF-8, it should be straightforward enough if the server knows how to decode it properly. I believe there is a telnet negotiation option to set the encoding so I'll see if I can enable that.

I think I have the Gmud source code hanging around somewhere, too. It was a great client for 1996. (The code was pretty awful though - also standard for 1996!

Wow, I didn't realize more people had gmud The guy who gave it to me made it sound like noone else possessed it

I did a little thinking about features that would be cool for a client. Consider these my MUD client wishlist.

* Ability to record the MUD gameplay into a standard video format (something YouTube compatible). Including the ability to add a soundtrack and do editing.

* Built-in ASCII art renderer: you select an image file, the MUD generates the best fit ASCII art rendition and puts it in a new window, from which you can copy/paste it.

* Ability to use other protocols besides telnet. It'd be sweet if you could MUD, and check your email, and browse FTP files, all in the same program. SSH support would also be sweet for us coder types.

* Optionally, the ability to simultaneously tune in to the broader network of users of the client, while MUDding. This would basically add a new channel to whatever MUD you're connected to, but only other users of the client would see it (and it'd be outside the physical laws of that MUD world, so you could use it while silenced, stunned, etc.) Mechanically, how this would work, is that besides the connection to the actual MUD, client users who chose to participate would also silently be connected to a central server owned by you, the client maker.

* Ability to generate statistical reports on things like word frequency, etc. For example, pull up a list of the top 500 most used words on a given MUD together with their usage frequency in percentage.

* An option to transmit text as it's typed, like Windows Telnet, instead of in individual blocks which are only sent upon pressing enter (like zMUD). Why? MUDs could take advantage of this to implement commands which don't require enter to be pushed.. for example, server-side macros. Along the same lines, an option so that ALL keystrokes (including things like arrow keys and function keys, which most clients don't transmit) get transmitted. Imagine an overworld map where instead of typing "n ENTER e ENTER", you press "up right" (the arrow keys).

Well, these are just some pipedreams, hope they inspire you or any other client writers to do some innovation

[Lanthum]

(I apologize ahead of time ... this is LOOOONG winded)

I've been thinking about custom clients for quite some time - as I would like to offer something a little more "original" with my new game (whatever century it ends up getting done ) - and it's left me with a thought:

Developers of MUDs are left with 2 choices when it comes to clients: to offer a custom client for their game, or not.  If they do, it will either increase the developement cycle for the game extensively, and/or cost a rather hefty amount of money to have someone else develope it.  And if they don't offer one, their players are left to choose from the collective pool of clients that are already out there.

What follows, of course, is just my opinion!  You have been warned!  
But I feel all of the clients out there now, for the most part, are VERY similar to each other.  And it seems to me, that most of the design time was given to the end player and little thought and design was ORIGINALLY given to the developers of the games the client would be used on.  And again, in my opinion, I think this has created an entire age of MUDs where the design of the game ultimately was influenced/dictated by the interface, instead of the interface being chosen because of the design of the game.

And in case all that's a little vague, take as one example spatial representation in MUDs.  While it has been evolving over the years, until recently I would say, most MUDs represented the space within their game by using the traditional "rooms", where 1 "node" = 1 room.  And a 10'x10' room within the game was spatially the same as a 100'x200' room - except for the description.  This traditional MUD design spawned a host of client programs with mappers, but as games evolved, developers had to choose whether they were going to use a different spatial system making it difficult for those old mappers to work, or just stick with the tried and true system to allow their players to use their mapper.

Originally Posted by I'm working on a new client, which I hope will mark a significant step forward for muds when it's done.

If this is true, I guess if I were creating it, I would put as much thought into designing a program that has different features and protocols that the MUD developers can choose from, as I did designing it for the player.  I'll admit that I have given little thought to the actual developement of a custom client, so it might not all be possible.  But I think it would be cool if MUD developers could "choose" what features were available for the client to offer to the player.

That way, the MUD could communicate the "layout" or choices to the client program and it could act accordingly.  Like for example the spatial system, if the game uses the 1 node = 1 room system, the client would use a typical mapper.  But if the game used a coordinate based system - maybe a different representation would be used.

Or maybe the MUD developer just wants to use actual pictures for locations, or a drawn map with an 'X' over it.  The client program could display the appropriate picture where ever the game developer specified.  Or if the MUD developer wants chats to go to a separate window, your game could communicate that to the client and the client program would take care of it.  Etc., etc.


I think the only way we can keep this hobby growing is if all aspects of it continue to evolve: servers, clients, websites, etc.  And for a new client to truly be innovative, I don't think it should force players and developers to design another game to fit within narrow ideas, but instead allow greater creativity.

[Kylotan]

Yes, in fact one major aim of my client will be to showcase some new features in my own servers. However I will gain more traction with the client if it supports other MUDs and any of their advanced features, and if the new features in question are based on exploiting well-known standards that other games can implement. That way hopefully the whole genre can progress together.

[scandum]

Originally Posted by Ability to record the MUD gameplay into a standard video format (something YouTube compatible). Including the ability to add a soundtrack and do editing.

It should be possible to create a special log syntax that adds a time stamp to each text and MSP message. That way you could play back a log file and edit it quite easily as well.

Originally Posted by Optionally,the ability to simultaneously tune in to the broader network of users of the client, while MUDding.

I ran a MMC (Mud Master Chat) server script for 3 months once and precisely zero people connected. I doubt it'll work unless you enable it by default, which in turn will annoy a lot of people who don't like phone home software.

Originally Posted by An option to transmit text as it's typed, like Windows Telnet, instead of in individual blocks which are only sent upon pressing enter (like zMUD).

How to negotiate character mode is a well kept secret =]

[shadowfyr]

Originally Posted by (scandum @ Mar. 30 2007,2:38) Originally Posted by Ability to record the MUD gameplay into a standard video format (something YouTube compatible). Including the ability to add a soundtrack and do editing. It should be possible to create a special log syntax that adds a time stamp to each text and MSP message. That way you could play back a log file and edit it quite easily as well.

Mushclient already supports that. You can set up a string that time stamps or does other things to the log. In fact, you can even pre-append HTML headers and post append HTML closing marks, so that its directly displayable as HTML *and* tell the client to export the log as HTML encoder colors, etc., so that it will display exacly as in the client when placed into such a page.

If you had some sort of special code that was designed to "replay" the things at the point where their timecode was, you could, I think, even intercept the log output and append your own codes to it. Or maybe not. I am not sure if there is a script callback for OnPluginLogWrite or somesuch. There is for damn near everything else though, so... lol

Hmm. Just checked. Nothing to script edit the log entries, yet.. Got to suggest that...

As for spacial coordinates that someone mentioned.. That could be handled in existing script supporting clients, just create code that strips out data on the "location" you are at, before displaying any text, then feed that data to what ever engine/map, etc. needs it.

Heck, one could, if the mud supported such a system, funnel such codes directly to an OpenGL engine that could reproduce EQ, WoW, etc. style 3D scenes from it. Your just talking about sticking 3D objects into the world, and part of making such a thing work is visibility of mobs *and* there locations. Doesn't matter if its a simple 2D map or a 3D one, though one with large granuality will look more like playing one of the old Ultima games, than a modern 3D one. I.e., monsters kind of dancing in place until they move, then "jumping" to the next closest coordinate to you. It all kind of depends on how many "steps" exist between coordinate locations in the world. True 3D worlds = lots (thousands), ones a mud might have = a few (less than 100).

A 2D Isometric like Falcon's Eye isn't that far of a stretch even for "existing" muds, if you wanted to create something like that to show the "rooms" you entered. On a fundamental level, the only real difference between text and the miriad of other methods used is *how* objects and mobs are represented in them. A client capable of triggers, and advanced enough script, could, concievably, do damn near anything, as long as a script can be implimented that understands the protocol being used and the security authentication needed to connect to the world's server(s). Even disconnnecting from one server and connecting to another... OK, that is a bit harder for most of them, since right now the "assumption" for muds is that they all run one only one server, and connecting to a second server while still "on" the current one, then logging off that first one and continuing on the new, isn't *expected* behavior for any mud that currently exists. Clients all assume that once you are on MyMud1.com you are not going to suddenly decide to connect to MyMud2.com in the middle of playing.

Mind you, it could be done in Mushclient, with the right plugins. It would mean using a master world that only works as the "input/output", redirecting all the stuff from the actually connected worlds to there using things like "simulate", then having script create new worlds with the proper plugins to handle redirection, the correct IPs/hostnames and do negotiations between them while transferring... Got to think about this a bit. Sometimes this client scares me.

[scandum]

Originally Posted by (shadowfyr @ Mar. 30 2007,5:16) Mushclient already supports that. You can set up a string that time stamps or does other things to the log. In fact, you can even pre-append HTML headers and post append HTML closing marks, so that its directly displayable as HTML *and* tell the client to export the log as HTML encoder colors, etc., so that it will display exacly as in the client when placed into such a page.

Not exactly what I was talking about. HTML logging sounds like a great idea, and isn't overly difficult to implement, but neither Firefox nor IE is capable of displaying log files of several megabytes.

Originally Posted by (shadowfyr @ Mar. 30 2007,5:16) If you had some sort of special code that was designed to "replay" the things at the point where their timecode was, you could, I think, even intercept the log output and append your own codes to it. Or maybe not. I am not sure if there is a script callback for OnPluginLogWrite or somesuch. There is for damn near everything else though, so... lol

The joys of over functionality =]

I brain stormed for a minute and wrote a 5 line script in tintin that creates a log file that plays back text in the order of appearance with milli second precision. As usual it's too difficult for most people to thinker up themselves, and once you start adding redundant functionality you end up with so much of it that nobody can find what they're looking for.