Top Mud Sites Forum Return to TopMudSites.com
Go Back   Top Mud Sites Forum > Mud Development and Administration > MUD Coding
Click here to Register

Reply
 
Thread Tools
Old 03-25-2007, 05:28 PM   #21
shadowfyr
Senior Member
 
Join Date: Oct 2002
Posts: 310
shadowfyr will become famous soon enough
Quote:
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.
shadowfyr is offline   Reply With Quote
Old 03-26-2007, 11:08 AM   #22
Kylotan
Member
 
Join Date: Jun 2003
Location: Nottingham, UK
Home MUD: Abattoir (Smaug)
Home MUD: ex-Jellybean (Smaug)
Home MUD: ex-Dark Chambers (Merc)
Posts: 174
Kylotan is on a distinguished road
Send a message via ICQ to Kylotan Send a message via AIM to Kylotan Send a message via MSN to Kylotan Send a message via Yahoo to 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.
Kylotan is offline   Reply With Quote
Old 03-29-2007, 03:26 AM   #23
erdos
 
Posts: n/a
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.
  Reply With Quote
Old 03-29-2007, 08:36 AM   #24
Kylotan
Member
 
Join Date: Jun 2003
Location: Nottingham, UK
Home MUD: Abattoir (Smaug)
Home MUD: ex-Jellybean (Smaug)
Home MUD: ex-Dark Chambers (Merc)
Posts: 174
Kylotan is on a distinguished road
Send a message via ICQ to Kylotan Send a message via AIM to Kylotan Send a message via MSN to Kylotan Send a message via Yahoo to 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!
Kylotan is offline   Reply With Quote
Old 03-29-2007, 03:07 PM   #25
erdos
 
Posts: n/a
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
  Reply With Quote
Old 03-30-2007, 08:42 AM   #26
Lanthum
Member
 
Lanthum's Avatar
 
Join Date: Oct 2002
Location: Suburbs of Chicago
Posts: 138
Lanthum is on a distinguished road
Send a message via MSN to 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.


Quote:
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.
Lanthum is offline   Reply With Quote
Old 03-30-2007, 11:24 AM   #27
Kylotan
Member
 
Join Date: Jun 2003
Location: Nottingham, UK
Home MUD: Abattoir (Smaug)
Home MUD: ex-Jellybean (Smaug)
Home MUD: ex-Dark Chambers (Merc)
Posts: 174
Kylotan is on a distinguished road
Send a message via ICQ to Kylotan Send a message via AIM to Kylotan Send a message via MSN to Kylotan Send a message via Yahoo to 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.
Kylotan is offline   Reply With Quote
Old 03-30-2007, 03:38 PM   #28
scandum
Senior Member
 
scandum's Avatar
 
Join Date: Jun 2004
Posts: 308
scandum will become famous soon enough
Quote:
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.

Quote:
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.

Quote:
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 =]
scandum is offline   Reply With Quote
Old 03-30-2007, 06:16 PM   #29
shadowfyr
Senior Member
 
Join Date: Oct 2002
Posts: 310
shadowfyr will become famous soon enough
Quote:
Originally Posted by (scandum @ Mar. 30 2007,2:38)
Quote:
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.
shadowfyr is offline   Reply With Quote
Old 03-31-2007, 07:46 AM   #30
scandum
Senior Member
 
scandum's Avatar
 
Join Date: Jun 2004
Posts: 308
scandum will become famous soon enough
Quote:
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.

Quote:
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.
scandum is offline   Reply With Quote
Old 03-31-2007, 06:12 PM   #31
shadowfyr
Senior Member
 
Join Date: Oct 2002
Posts: 310
shadowfyr will become famous soon enough
Quote:
Originally Posted by (scandum @ Mar. 31 2007,06:46)
Quote:
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.
Posted a suggestion about a log intercept in Mushclient and got, "Well, you can just have a trigger and an alias that do a '*' match and uses 'keep evaluating'." Only problem is, the client has three text streams - 1. Server output, 2. User input, 3. Notes/Colornotes produced by script, the later which you can't "trap" that way. Haven't heard a response back about that later issue yet, but... as of last night there was also this announcement:

http://www.gammon.com.au/forum/?id=7733&page=999

Mushclient is now freeware and as soon as Nick can rip out the code for user registration and the remains of the original proprietary code for spell checking, its going to also go open source. Any "missing" features at that point can be integrated into the client by anyone willing to spend the time to code it, including replacing the existing custom output window with one that supports correct inlining of MXP objects and text positioning commands (not sure how you really mix those though..), correct sound playback support (we have something, but its script run and flaky), parallel threads to download files (currently only available in the zChat protocol support, not for things like images/files), etc.

If its currently incomplete, partly broken or missing, it will now be possible to build a new version that does it.
shadowfyr is offline   Reply With Quote
Old 04-02-2007, 11:05 AM   #32
scandum
Senior Member
 
scandum's Avatar
 
Join Date: Jun 2004
Posts: 308
scandum will become famous soon enough
Quote:
Originally Posted by (shadowfyr @ Mar. 30 2007,5:16)
Mushclient is now freeware and as soon as Nick can rip out the code for user registration and the remains of the original proprietary code for spell checking, its going to also go open source.

If its currently incomplete, partly broken or missing, it will now be possible to build a new version that does it.
I wouldn't get your hopes up. Talking about features is fun, but few people have the required skills to add a wide range of functionality. And those that do generally have better things to do with their time.
scandum is offline   Reply With Quote
Old 04-02-2007, 01:31 PM   #33
shadowfyr
Senior Member
 
Join Date: Oct 2002
Posts: 310
shadowfyr will become famous soon enough
Quote:
Originally Posted by (scandum @ April 02 2007,10:05)
Quote:
Originally Posted by (shadowfyr @ Mar. 30 2007,5:16)
Mushclient is now freeware and as soon as Nick can rip out the code for user registration and the remains of the original proprietary code for spell checking, its going to also go open source.

If its currently incomplete, partly broken or missing, it will now be possible to build a new version that does it.
I wouldn't get your hopes up. Talking about features is fun, but few people have the required skills to add a wide range of functionality. And those that do generally have better things to do with their time.
Bah.. We are talking about people that have coded mappers for Battletech based muds for it, do lots of complex stuff with the Lua scripting, done code work on path mapping for a mapper we don't have yet and even, in my case, experimented with docking windows with the main client window (and that was before you could "access" the main frame handle from the script or retrieve size/position data from it). I have every reason to believe that people "will" work on new features and changes for it from among the existing users.

But yeah. That is one potential problem.
shadowfyr is offline   Reply With Quote
Reply


Thread Tools


Extended mud client protocols - Similar Threads
Thread Thread Starter Forum Replies Last Post
AL Client Lorccan MUD Coding 0 04-11-2005 03:21 PM
An Invitation Extended to You Aidan_RoD Advertising for Players 2 02-18-2005 12:55 AM
New KDE/Linux mud client: KMC cronel MUD Announcements 16 03-13-2003 04:34 PM
Who is the client? Neranz Laverani MUD Administration 0 09-04-2002 02:48 PM
Deadlines for Summer MCM Issue Extended Thoric MUD Announcements 0 05-01-2002 12:36 PM

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT -4. The time now is 10:00 PM.


Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Style based on a design by Essilor
Copyright Top Mud Sites.com 2014