Does anyone know where it can be found? I looked at http://www.mudstandards.org/forum/viewforum.php?f=7 but that's obviously just a discussion about the protocol. Comparing the GMCP data sent from Aardwolf also reveals that a lot that is sent is not even discussed in that forum.

The discussion about the standard also seem, unfortunately, to be inactive .

From my point of view I'm thrilled with GMCP. The need for a protocol like this was identified years ago and there have been some attempts to solve it since (notably the sadly ignored ZMP protocol). The fact that, very quickly, the top three mud clients plus all of IRE's games and large muds like Aardwolf support functionality like this is very exciting and I hope the popularity of both the clients and the games it works on today promotes further adoption by the mud community as a whole.

It's an easy protocol in implement both client and server-side. The protocol really specifies the mechanism letting the semantics be defined on the package level. Does your mud server need specific information transmitted out of band? No problem! Here's a well defined generic data transport protocol. It's a beautiful thing!

I'm very happy that Zugg, Nick, Vadi, Lasher, and the IRE folks pushed forward with implementing the spec and not letting it get bogged down in the morass that was the mudstandards.org thread.

We'll see how GMCP adoption community-wide pans out but we're sure off to a good start.

From my point of view I'm thrilled with GMCP. The need for a protocol like this was identified years ago and there have been some attempts to solve it since (notably the sadly ignored ZMP protocol). The fact that, very quickly, the top three mud clients plus all of IRE's games and large muds like Aardwolf support functionality like this is very exciting and I hope the popularity of both the clients and the games it works on today promotes further adoption by the mud community as a whole.

Similar protocols already existed. E.g ZMP like you mention but also MXP and MCP. The big benefit of MXP is that there is a specification, but I am sure ZMP will get that too eventually. Still abit disappointed that there is no draft.

Quote:

It's an easy protocol in implement both client and server-side. The protocol really specifies the mechanism letting the semantics be defined on the package level. Does your mud server need specific information transmitted out of band? No problem! Here's a well defined generic data transport protocol. It's a beautiful thing!

Is GMCP only a transport protocol? There is no support for creating things like gauges/frames like MXP has?

The actual GMCP protocol discusses on mudstandards.org really only got as far as specifying the low-level data transport. The protocol as defined here: http://www.mudstandards.org/forum/viewtopic.php?f=7&t=107 is what CMUD, MUSHClient, MUDlet, IRE, and Aardwolf are all using and when somebody gets some free time, it will eventually get posted to the Wiki.

The actual *messages* sent via GMCP are still somewhat MUD dependent. The entire GMCP protocol discussion fell apart before we could really get into the important and useful discussions of specific messages. None the less, IRE and Aardwolf are both implementing some of the same messages.

GMCP is mostly just a transport protocol to send information between the server and client "behind the scenes" in a standard way. It does *not* define any specific client presentation behavior, such as gauges. However, it's trivial in CMUD to create a GMCP trigger and store the GMCP data into a normal CMUD variable that you have created your own gauge for.

Asking all client makers to even implement something like gauges is wishful thinking. Nobody other than zMUD/CMUD ever implemented the gauges in MXP as far as I know. Some MUDs don't even like the concept of doing proper telnet option negotiation. All you need to do is read the mess at mudstandards.org to see how difficult it can be to come to any sort of agreement. And unfortunately, some people get side tracked away from the technical discussions into stuff like free MUDs/clients vs non-free MUDs/clients and start making personal attacks that drive people like me away.

I'm pretty happy with what we ended up with for GMCP and am glad that some big MUDs are supporting it and not getting bogged down by the vocal minority that started posting on mudstandards.org. I think it could have gone a lot further and made mapping MUDs even better, but as least we ended up with something. Then it all fell apart and it just wasn't worth my time to post on those forums anymore. I think the Wiki part of the site will continue to be a useful repository for MUD protocols specs, but the forum has pretty much died.

orphean: Thanks for your good comments. That's exactly what I personally intended GMCP to accomplish and am happy that it did, even though the process itself left a sour taste.

I'm pretty happy with what we ended up with for GMCP and am glad that some big MUDs are supporting it and not getting bogged down by the vocal minority that started posting on mudstandards.org. I think it could have gone a lot further and made mapping MUDs even better, but as least we ended up with something. Then it all fell apart and it just wasn't worth my time to post on those forums anymore. I think the Wiki part of the site will continue to be a useful repository for MUD protocols specs, but the forum has pretty much died.

Maybe the best way to get something going is if a few people write a draft of the protocol, and then post that draft for discussion? Someone needs to act as a project leader to direct the discussion - else it will just get stuck. Who is responsible for the GMCP standard?

We'll, we kind of tried that too. It also didn't work very well and I promised not to talk about details in public.

As you'll see in the forum post linked above, I was the one who posted the draft proposal to try and move it forward. The idea of using JSON as the data format came from several people and I was certainly a big supporter of it. But people were talking about using JSON before I posted the spec. So I did sort of act as "project leader", but I'm not claiming ownership...it really was a group effort. But you can read the discussion over there yourself. It's mostly intact except for some horribly personal attacks that got removed.

No, MXP is completely different. MXP is designed for rendering markup of the output from the MUD, similar to HTML on web pages. So MXP is used for colors, hyperlinks, etc. Some extensions to MXP were added for mapper data that is hidden from the main display, but that was a bit of a kludge and not supported by most clients or MUDs.

GMCP is intended for sending rich data "behind the scenes" between the client and server. Data sent via GMCP is not displayed to the player. It is also not necessarily synchronized with the regular text from the MUD. GMCP is used for sending raw data such as character inventory, stats, detailed map/room data, etc.

GMCP was needed because MXP was never designed for sending structured data, such as tables and arrays and extending MXP to handle this really was beyond the original intent of the spec. GMCP was based upon some success Iron Realms had with their ATCP protocol using the Telnet subchannel communications to create a parallel data channel separate from the normal MUD output. Using the JSON data format with the Telnet subchannel provided the structured data protocol that was needed.

So MXP and GMCP complement each other and both are useful. MXP is not going away. If you find yourself needing to modify the rendering of the MUD text (color, font, etc) then use MXP. If you want to send structured raw data to the client, then use GMCP.