09 Mar, 2009, David Haley wrote in the 1st comment:
Votes: 0
Elanthis, what's the current deal with ZMP? You're the person who wrote it, so you get my question. :wink:
09 Mar, 2009, elanthis wrote in the 2nd comment:
Votes: 0
Uh, the deal is the base spec is done. Nobody uses it, due to equal parts my lack of evangelical determination and the inability of 99% of MUD coders to handle TELNET sub requests properly. The design was based on the assumption that MUDs all use TELNET so a TELNET-based protocol would be stupid-easy to implement in any MUD.

There is a need for more packages, which may make it far more attractive. I don't know what people want and most of the things I want to do with ZMP are very highly tied to my specific MUD's design and are not applicable to the average Diku MUD, so I haven't really pushed it much.

I'm also interested in packages for generic UI elements for graphical clients, e.g. status bars and the like. Given the lack of any suitable graphical clients that are Open Source and my lack of desire to write any such client that isn't HTTP/CSS/JavaScript based (which isn't possible without a lot of insane effort and hacks due to the lack of socket support in JavaScript), that hasn't gotten far. I don't want to make official packages if I don't have any implementation experience in a client, for obvious reasons. I've been thinking of hobbling together a WebKit/GTK+ client, but I've got a million other projects on my plate already.

To my knowledge, the only clients that implement ZMP are MudMagic, GNOME-MUD, and the clc client I wrote for testing, and the only server that implements ZMP is AweMUD/SourceMUD.
09 Mar, 2009, David Haley wrote in the 3rd comment:
Votes: 0
I'm curious about it because it might be relevant for my MUD project. I think I'm probably able to get telnet working correctly. :wink: Nick Gammon has done something custom with Aardwolf's developer to drive mini-windows. (If you don't know of that work yet, I strongly recommend checking it out – I can point you to it.) I wouldn't mind comparing that with the "proper ZMP way". I might also be able to lobby him for implementation in MUSHclient; it might be possible to do with triggers, but that has the usual packet problem. (In MUSHclient you can read and I think even filter things at the packet level.) If it's possible with triggers I would do it myself.

Anyhow I'll poke around the ZMP spec some more and see how it works. The examples seem kind of simple from just a brief perusal of the website, so I'll have to give it a think to see more of it.
09 Mar, 2009, elanthis wrote in the 4th comment:
Votes: 0
ZMP is pretty simple. It's in fact very, very similar to MSSP, hence why I advised Scandum to avoid going that route. You enable ZMP, and it is two-way communications (clients can send data to the server as well as receive it). The sub-request is basically just a NUL-byte separated list of parameters, with the first parameter being the ZMP command name and the rest being data for the command. There's a precious few 'core' ZMP commands, some color stuff (which reflects "good use" of color and isn't so useful for the rainbow-splash people), and that's it.
10 Mar, 2009, David Haley wrote in the 5th comment:
Votes: 0
Using subneg makes sense for something like ZMP. Do you have any theories as to why it didn't catch on? I imagine that many client authors could handle it. Nick has a habit of doing things 'by the books' [1]. I wonder why he didn't do this: the only mention of ZMP on his forums is by some dude who tends to talk about things he doesn't understand, and he doesn't really have much interesting to say about it. But sure, I can imagine that the server authors would be the problem.

Well, like I said, if you think ZMP is going somewhere and there is interest in developing it, I can lobby for it in MUSHclient and even implement parts (or all) of it. But if server adoption is low in the first place, there is indeed not much point except for whatever use I would make of it in my own MUD. (But really, I was planning on doing something like this anyhow and rolling my own, so I'll probably do all of this anyhow. So, yeah.)

[1] In fact, Nick tends to do this correctly, such that when other clients (whose name starts with Z but which shall otherwise remain anonymous) do something incorrectly (like assume MXP is always on, because server authors can't get the subneg right — hmmmmm, there's a trend here) people come to Nick telling him that his client is broken because it doesn't parse the MXP correctly.
10 Mar, 2009, elanthis wrote in the 6th comment:
Votes: 0
Quote
Using subneg makes sense for something like ZMP. Do you have any theories as to why it didn't catch on?


I stated two of my theories in the original response to your question. :)

I suppose a third is the chicken and egg problem. You claim that there is little point in pushing for it in MUSHclient is there is no server adoption, but who is going to bother implementing it in a server if no clients support it?

I really should have ust personally written patches and snippets for popular clients and servers. I guess that goes back to the "poor evangelist" theory I already gave.

Hmm. I'll submit a patch for tbaMUD if you are serious about doing one for MUSHclient. (Not sure if a patch for tbaMUD could easily be turned into a snippet for common Diku/ROM MUDs… I can never keep the genealogy of all these MUDs straight.)
10 Mar, 2009, Vassi wrote in the 7th comment:
Votes: 0
elanthis said:
Uh, the deal is the base spec is done. Nobody uses it, due to equal parts my lack of evangelical determination and the inability of 99% of MUD coders to handle TELNET sub requests properly. The design was based on the assumption that MUDs all use TELNET so a TELNET-based protocol would be stupid-easy to implement in any MUD.

There is a need for more packages, which may make it far more attractive. I don't know what people want and most of the things I want to do with ZMP are very highly tied to my specific MUD's design and are not applicable to the average Diku MUD, so I haven't really pushed it much.

I'm also interested in packages for generic UI elements for graphical clients, e.g. status bars and the like. Given the lack of any suitable graphical clients that are Open Source and my lack of desire to write any such client that isn't HTTP/CSS/JavaScript based (which isn't possible without a lot of insane effort and hacks due to the lack of socket support in JavaScript), that hasn't gotten far. I don't want to make official packages if I don't have any implementation experience in a client, for obvious reasons. I've been thinking of hobbling together a WebKit/GTK+ client, but I've got a million other projects on my plate already.

To my knowledge, the only clients that implement ZMP are MudMagic, GNOME-MUD, and the clc client I wrote for testing, and the only server that implements ZMP is AweMUD/SourceMUD.


I've written ZMP subnegotiation into my own graphical client. I'd like to, when done, pare down the features that are highly specific to my MUD and release the client as a basic Telnet app with ZMP goodness. For now, I like the idea of letting ZMP register styles with the client so that you don't have to send down clouds of ANSI all the time, you'd just declare your styles (like you would in CSS) and then push a simple sub negotiation down to declare which style is the current default.

Registering them with the client allows the users to edit them to their liking, in a much more intuitive way than changing your ANSI settings would. I.E. You can clearly see the "Object Name" style and change that rather than inferring that because objects are displayed as yellow you need to reinterpret yellow as something else (which could screw with other things that the mud uses yellow for).

That and the ability to register gauges and then set them, etc. The client is written in .NET, so with Mono 2.0 here I would eventually like to see it on all platforms.

Edit: I'd be highly interested in engaging in some discussion about some more 'standard' packages. With .NET and WPF I feel very confident that I can produce a strong Windows client, unfortunately Mono has no plans to implement WPF for Linux, though. I'd have to learn one of the native graphic libraries to produce the same kind of fidelity, so porting it that way would be secondary.

Still, having a couple of options (especially pretty ones) would give incentive for MUD owners to take notice. I'm especially keen on offering options for some decent to good looking GUI options such as round-timers, gauges, store dialogs, and maps to name a few.

EditEdit: At the risk of being self-promoting I'll post a link to the last preview video of the client I'm working on, if you stick with the first two minutes (the other 18 are probably not that interesting to you) you can see the kind of GUI elements we've got. http://www.cyra.ws/clientpreviewed/
10 Mar, 2009, elanthis wrote in the 8th comment:
Votes: 0
Quote
With .NET and WPF I feel very confident that I can produce a strong Windows client, unfortunately Mono has no plans to implement WPF for Linux, though. I'd have to learn one of the native graphic libraries to produce the same kind of fidelity, so porting it that way would be secondary.


What about using the subset there-of used in Silverlight? Once Moonlight 2.0 (the Open Source implementation of Moonlight compatible with Linux, via Mono) is out, I plan on getting involved in using it, assuming the Web hasn't caught up by then solid networking APIs.

Mono makes it easy to develop stand-alone Moonlight/Silverlight-based apps.

So far as standard packages, the list of things that comes to mind most would include the following (neither in order of importance nor difficulty):

* mapper (8-directional grid would be a fine start)
* chat windows (separate out ooc chat from main game window)
* status gauges and boxes (hp bars, round timers, coinage boxes, etc.)
* simple paper dolls (advanced damage tracking, be it for humanoids, weird creatures, vehicles, or so on)
* sound, backgrounds, images (some MUDs like to spice things up with a little media – I don't, but that's just me)
* non-modal dialogs (stores, npc conversation trees, character creation etc.)

Many of those require two-directional coordination. For example, a chat package is likely going to want client->server commands for getting a list of valid chat channels, subscribing and unsubscribing to a channel, sending messages to a channel, sending messages to a player, creating channels (with permission flags, e.g. guild-only, staff-only, etc.), and closing channels. The server->client commands would mostly be responses (ZMP has no native concept of a command return value – they're just commands that are only used as responses to other commands) and a few messages. Things like new message, channel created/destroyed/modified, access denied and other error messages, and so on.

Putting together a spec for a chat package would be dead simple. Might be a good start as an exercise for a community package-building project.

… probably worthy of its own thread. :)

The one thing I guess ZMP does not need is a set of detailed status commands, thanks to Scandum. :)
10 Mar, 2009, Vassi wrote in the 9th comment:
Votes: 0
elanthis said:
What about using the subset there-of used in Silverlight? Once Moonlight 2.0 (the Open Source implementation of Moonlight compatible with Linux, via Mono) is out, I plan on getting involved in using it, assuming the Web hasn't caught up by then solid networking APIs.


Silverlight was still mostly a curiosity when I began working on the client, 2.0 had been promised but wasn't out yet. Rumor has it that porting a WPF app to a Silverlight 2.0 app is not that painful. Unfortunately, like all of us here, there are only so many things I can commit to. It's also unclear how well Moonlight will work. So far I've been burned even by Mono 2.2 where there's one or two methods methods that don't work that I need. At this point, though, I will probably stop and look at Silverlight once the main client is done. It could be that you're right and it would make more sense to go that route when hacking the client down to size.
10 Mar, 2009, David Haley wrote in the 10th comment:
Votes: 0
What exactly does it mean to provide a package other than specify the list of commands etc.? The color package for instance is all well and good, except that clients still need to support it. So, making new packages won't really help unless there's some belief that clients will implement them. This is a particular problem for relatively fancy GUI packages like dialog trees, various split and/or overlapping windows, etc.

I agree that there is a chicken and egg problem here. From my perspective, I'd like to use something like this eventually as I work on advanced features for my own game. Fancy GUI widgets are indeed a priority for me. MUSHclient's recent support for mini-windows makes this possible, to some extent, although there is no GUI framework to speak of and you have to do everything yourself. If I could describe the widgets to use in some standard way, life would be a lot easier.
10 Mar, 2009, Tyche wrote in the 11th comment:
Votes: 0
elanthis said:
To my knowledge, the only clients that implement ZMP are MudMagic, GNOME-MUD, and the clc client I wrote for testing, and the only server that implements ZMP is AweMUD/SourceMUD.


TeensyMUD supports it. BTW, where is the protocol located now on the web?
10 Mar, 2009, David Haley wrote in the 12th comment:
Votes: 0
Here (google zmp mud)

Is 'clc' a good client to test ZMP stuff with, or should I try Gnome MUD instead? Just looking for something simple to see what happens…
10 Mar, 2009, Davion wrote in the 13th comment:
Votes: 0
Split from here. On a secondary (yet fairly related note) what would be the chances of getting a ZMP article written, Elanthis?
10 Mar, 2009, Vassi wrote in the 14th comment:
Votes: 0
David Haley said:
What exactly does it mean to provide a package other than specify the list of commands etc.? The color package for instance is all well and good, except that clients still need to support it. So, making new packages won't really help unless there's some belief that clients will implement them. This is a particular problem for relatively fancy GUI packages like dialog trees, various split and/or overlapping windows, etc.

I agree that there is a chicken and egg problem here. From my perspective, I'd like to use something like this eventually as I work on advanced features for my own game. Fancy GUI widgets are indeed a priority for me. MUSHclient's recent support for mini-windows makes this possible, to some extent, although there is no GUI framework to speak of and you have to do everything yourself. If I could describe the widgets to use in some standard way, life would be a lot easier.


The problem right now with ZMP is that it's just a means to an end, that is to say it defines a way to send messages but doesn't really define any messages outside of the basic ones which consist of an Ident command, a ping command, and a standard way to check for support of other commands.

I don't think it's really that big of a conundrum, or chicken and egg, at all. The simple reason it has not been picked up is because there isn't a client that has any interesting packages for use. To that end, I would agree that working on a core set of widgets so that they can be used and configured by the MUD, rather than manually by the user, should be a priority. I feel these kinds of things are less invasive to add to a codebase than other things like a completely different way to handle chat, coloring, etc. These are the things that would gain adoption the quickest.
10 Mar, 2009, elanthis wrote in the 15th comment:
Votes: 0
David Haley said:
What exactly does it mean to provide a package other than specify the list of commands etc.? The color package for instance is all well and good, except that clients still need to support it. So, making new packages won't really help unless there's some belief that clients will implement them. This is a particular problem for relatively fancy GUI packages like dialog trees, various split and/or overlapping windows, etc.


A package is just a list of related commands in a namespace, e.g. chat.open, chat.close, chat.send, etc. There are also commands to check if the other side of the connection supports any given command, so your MUD server can check to see if the packages (or individual commands) it wants to use are supported by the client or not.

While it's recommended that anyone implementing a package implement the whole thing, there's no real technical way to enforce that, so for certain complex packages it may be best to check for individual commands. For simpler packages, you can just ask if e.g. chat.* is supported.

Quote
I agree that there is a chicken and egg problem here. From my perspective, I'd like to use something like this eventually as I work on advanced features for my own game. Fancy GUI widgets are indeed a priority for me. MUSHclient's recent support for mini-windows makes this possible, to some extent, although there is no GUI framework to speak of and you have to do everything yourself. If I could describe the widgets to use in some standard way, life would be a lot easier.


When one gets to the point of describing GUIs, it makes the most sense to pick some standard existing layout spec and just speak that. e.g., HTML or XForms. That is especially useful given that GUI development is going the way of using HTML/CSS for everything, even for apps that aren't actually part of the Web. (QT for example now ships a WebKit component, GTK+ is looking at adding WebKit/GTK sometime in the future, Windows has always had the Explorer component, and so on – they're just really advanced canvases with powerful existing GUI design tools.) MUD clients often want to use a pure text interface, though; I'm not sure if something like Lynx or ELinks can be used as a library or not.

If I were to design a dialog language just for MUDs, I would probably limit it solely to multiple-choice selections. It might be useful if we had some solid examples of what people WANT out of a dialog/gui system, though.

Quote
Is 'clc' a good client to test ZMP stuff with, or should I try Gnome MUD instead? Just looking for something simple to see what happens…


I'm not sure if the current git version has any implementation bugs or not. It is a VERY VERY simplistic client. It's sole purpose was testing protocols, namely TELNET+ZMP and the WebSock.

I just pushed an update that removed WebSock (lost interest in developing that, as the whole HTML5 spec seems up in the air now, and a proxy server seems like an easier way of supporting it anyway) and fixed up an obvious missing critical feature in clc.

clc doesn't do any logging of the ZMP commands received or sent, which would probably be pretty damn useful for debugging. Would be easy to add, and I'd take a patch for it if anyone wants to implement it. I may do it myself, but likely not today.

I once had a modified copy of MUDix with full ZMP support, but the git repo on sourcemud.org appears to be just a plain MUDix import. No idea what happened to all my mods for it; that sucks. (I was maintaining the terminal-only version of MUDix as the author had abandoned it to work solely on gMUDix, but he took the reins back some years ago.)

Davion said:
On a secondary (yet fairly related note) what would be the chances of getting a ZMP article written, Elanthis?


I'd be happy to write one. I am also planning on writing a new "how to implement TELNET" article, since my old one kind of sucks. I think it might be a better idea to get a few more clients out there using it (sounds like we have a decent if small collection of servers supporting it already) so anyone reading said article has something to play around with.

If I might ask, what is drawing you folks to ZMP over MXP? (I think MXP sucks on a number of levels, but I'm interested to know if others simply agree with my assessments, or if there are other reasons.)
10 Mar, 2009, Scandum wrote in the 16th comment:
Votes: 0
I looked into adding a ZMP event system for tintin so people could use it in their scripts, but the usage of NUL bytes makes that impossible (without having to rewire half the client). I wouldn't be surprised if zmud and mushclient have the same issue.
10 Mar, 2009, David Haley wrote in the 17th comment:
Votes: 0
elanthis said:
It might be useful if we had some solid examples of what people WANT out of a dialog/gui system, though.

See the examples in this thread. Basically, several things are moved to other layers on the screen, with mouse over and so forth. It lets you display information in a way that's easier to manipulate. For instance, you can mouse over the items in the inventory list to get more detailed stats on the item – just like you would in a graphical client.

(Somewhat amusingly and unfortunately, MUSHclient's integration with Aardwolf works using what is essentially a reinvented ZMP. I guess they hadn't heard of it when they did all this stuff.)

elanthis said:
When one gets to the point of describing GUIs (…) HTML/CSS (…) WebKit (…)

It seems reasonable enough to me to use something like this. It's a problem for me personally because MUSHclient's miniwindows work by having you draw on a "raw" canvas, that is, widgets would need to be implemented and something like HTML/CSS would be a nightmare to implement from scratch. (Basically, it wouldn't happen.) I'm not strictly speaking wedded to MUSHclient but I really like it as a client, it has a lot going for it. Nick has been toying with the idea of making a new client that's cross-platform etc. which would be very nice, and if he actually goes forward with that I'll suggest making this miniwindow stuff more of a priority from the beginning with advanced GUI toolkits like the above.

Scandum said:
I wouldn't be surprised if zmud and mushclient have the same issue.

I would be surprised if MUSHclient had the issue. I'm not sure why NULs are a problem? Anyhow, MUSHclient lets you see the packet stream directly, so you could handle NUL bytes from the scripting side even if the core couldn't (which would be sort of surprising to me).
10 Mar, 2009, elanthis wrote in the 18th comment:
Votes: 0
Scandum said:
I looked into adding a ZMP event system for tintin so people could use it in their scripts, but the usage of NUL bytes makes that impossible (without having to rewire half the client). I wouldn't be surprised if zmud and mushclient have the same issue.


What, are they using NUL-terminated buffers instead of keeping a separate buffer length variable? Wouldn't surprise me. 99% of servers and clients _need_ their TELNET handling rewritten to safely use ZMP anyhow. More complex ZMP commands could be well over the maximum packet size, could include embedded newlines, etc.

Actually, if NUL bytes are that big of a problem, I am interested in finding out how those clients deal with NAWS, since a NAWS sub request usually includes two NUL bytes. The NAWS data are just two 16-bit network-byte-order integers, so any width/height under 255 is going to include a NUL byte.
10 Mar, 2009, Vassi wrote in the 19th comment:
Votes: 0
elanthis said:
If I might ask, what is drawing you folks to ZMP over MXP? (I think MXP sucks on a number of levels, but I'm interested to know if others simply agree with my assessments, or if there are other reasons.)


ZMP is easier to implement, in terms of parsing, and because it uses Telnet you don't have to worry about the open and secure tags and other such shenanigans. I like MXP in concept, but I've also heard it isn't implemented correctly in ZMUD in the first place, which sabotages any other implementations.

Besides all that, I think most of us are really just looking more at using it to setup and control some more specialized widgets, where MXP is highly concentrated around making the text itself pretty or putting it in other frames.

PS - Tag soup killed my cat. I hate HTML.
10 Mar, 2009, elanthis wrote in the 20th comment:
Votes: 0
Vassi said:
The problem right now with ZMP is that it's just a means to an end, that is to say it defines a way to send messages but doesn't really define any messages outside of the basic ones which consist of an Ident command, a ping command, and a standard way to check for support of other commands.


True enough.

Quote
I don't think it's really that big of a conundrum, or chicken and egg, at all. The simple reason it has not been picked up is because there isn't a client that has any interesting packages for use. To that end, I would agree that working on a core set of widgets so that they can be used and configured by the MUD, rather than manually by the user, should be a priority. I feel these kinds of things are less invasive to add to a codebase than other things like a completely different way to handle chat, coloring, etc. These are the things that would gain adoption the quickest.


I would really recommend aiming for the simpler stuff first – powerful widgets are going to be a nightmare, as I detail a bit below.

I think chat, context menues, a compass, and status bars would probably be the best ones to start with. I outlined what I think a chat package needs above. Context menues would be similar to what MXP has: just a way of "marking up" text so that it can be clicked and a menu pops up, and when an item is clicked it sends a command to a server. For example, you might markup every object in the room with a menu that has "examine" -> "look #3457", "pick up" -> "get #3457", "use" -> "use #3457", etc. Different objects might even send different menues, so that a fountain might have a "drink" option instead of "use." A MUD that makes extensive use of menues like that and a compass could conceivably be played with absolutely no typing except for talking/chatting. (And heck, if a client integrates DragonSpeak or whatever the popular voice->text engine these days is, even that typing could be eliminated.)

Could help in opening MUDs up to people like some of my friends, who type at about 1 word a minute – they don't even play NWN or the likes online because there's no integrated voice chat. Also makes it far more feasible to get MUD clients in Xbox Arcade or other gaming consoles where typing is an absolute bitch.

David Haley said:
It seems reasonable enough to me to use something like this. It's a problem for me personally because MUSHclient's miniwindows work by having you draw on a "raw" canvas, that is, widgets would need to be implemented and something like HTML/CSS would be a nightmare to implement from scratch. (Basically, it wouldn't happen.) I'm not strictly speaking wedded to MUSHclient but I really like it as a client, it has a lot going for it. Nick has been toying with the idea of making a new client that's cross-platform etc. which would be very nice, and if he actually goes forward with that I'll suggest making this miniwindow stuff more of a priority from the beginning with advanced GUI toolkits like the above.


HTML is way complex, I agree, which is why I didn't just start using it in the spec from the start. I simply don't know what the best way forward is. Especially as your GUI examples are way more complex than what I was thinking of using myself. For example, instead of having a navigation subwindow that the MUD defines with its own text rendering, I was planning on just having a separate compass package to let the MUD send a list of exit directions (the 8 cardinal directions, up, down, in and out, probably) and expect clients to graphically render them however they wanted (text, image overlays, whatever) and clicking them would just send a compass.go command back to the server with the clicked direction.

For inventory, a game engine like mine can't reliable use a simple list. Inventory would appear more as a modern graphical game, with a paper doll showing the equip slots, which can include containers that can be clicked to open and view the contents.

We end up needing either one hell of a complicated and advanced GUI system package that handles all these needs, or we need several separate specialized packages for different use cases.

I have no idea what the right way forward is here. Maybe having a subwindow package that behaves like MUSHclient and a separate set of specialized GUI packages for more graphically-intensive clients would be the right way to go.
0.0/108