Mudlet - Forum

Hello Mudlet dev team,

I'm a dev and player of the MUD called MUME and I want to add support for it to Mudlet.

Unfortuantely, MUME has a custom protocol to send data in-band which is vastly different from how the Mudlet architecture currently works with GMCP and other out-of-band protocols. The custom protocol is called MPI which unfortunately isn't negotiated using Telnet handshakes due to historical design reasons. Instead, the client negotiates settings using a special character prefix "~$#E". Through this handshake MUME can then submit extra information as XML. This has been very useful given the development of our own mappers which work as a pass-through and remove the XML tags so that clients don't need to understand them. Mudlet could be the first client/mapper to understand both.

How do you guys feel about such an addition? I know the protocol and XML-parsing engine do not fit into the Mudlet architecture very gracefully but I'm open to try and make changes to standardize things.

I would really prefer to not have to fork Mudlet

Thanks,
Jahara

Hiya

Is this something you can implement with triggers? Gagging in Mudlet client-side is really efficient.

From there on you could create a package, and offer to install it to new players via http://wiki.mudlet.org/w/Manual:GMCP_Extensions. This will work even on the current Mudlet 2.1, anyone who connects to your game will get that stuff.

Hi Vadi,

Thanks for getting back to me so quickly! Responses below:

Vadi wrote:Is this something you can implement with triggers? Gagging in Mudlet client-side is really efficient.

Yes, that is an interesting proposition. However, it isn't as simple as just gagging out the XML because we would need to parse the entire stream, fire off relevant mapper actions or user triggers, and then unescape any HTML characters within it for display in the terminal. I understand that it is do-able in Lua but wouldn't this cause performance problems as explained by Heiko when designing MXP parsing? I'll investigate the feasibility but I would prefer to code this in C++ rather than in Lua primarily due to performance and secondly because I can re-use code from our mappers.

Also, I'm also not sure if user actions will still be able to work if we script all this parsing behavior in Lua.

Please let me know what you think is best from an architectural point of view!

Vadi wrote:...offer to install it to new players via http://wiki.mudlet.org/w/Manual:GMCP_Extensions.

MUME doesn't support GMCP but I could talk to my colleagues and see what they think. I do like the idea of any sort of packages being updated outside of Mudlet releases. I assume we don't have to go with the GMCP route and could always just download an updated package in Lua from a static HTTP URL location though, correct?

Another question, how do you guys feel about adding QtPluginsupport to Mudlet for additional customizability? Our mapper is already coded in Qt and should be able to connect to Mudlet via a C++ plugin interface and EventHandlers to receive signals. I've coded a prototype hybrid client/mapper using this solution and it worked pretty great. If this sounds interesting to you guys I can propose a common plugin interface.

Thanks again,
Jahara

We'll have a developer meeting next week so I'll pen this up. I'm always happy to see Mudlet more widely used, so I'm interested in working out a solution, but I'm wary of adding support for a protocol only one MUD uses and others aren't likely to adopt, especially when none of the core developers play it.

C++ plugins aren't a good idea either, providing builds for all the platforms we support isn't easy and we'd hate to see users get left out because somebody can't compile their plugin for some platform. QML might fill this space, though.

You don't have to go the GMCP route but adding in some shell support would allow your package to get installed initially when a user connects, instead of them having to install the package on their own.

Vadi wrote:We'll have a developer meeting next week so I'll pen this up.

Let me know if you would like to me to attend and defend my case

Vadi wrote:...especially when none of the core developers play it.

True, but we still have over 15 people that maintain and develop it on a more-or-less active basis.

Vadi wrote:C++ plugins aren't a good idea either, providing builds for all the platforms we support isn't easy and we'd hate to see users get left out because somebody can't compile their plugin for some platform.

Yes, that is one of the usage problems. Of course, they could be downloadable just like packages are. Versioning and architecture could just be part of the interface and package names although this would all ultimately be up to the package maintainer to decide.

Vadi wrote:You don't have to go the GMCP route but adding in some shell support would allow your package to get installed initially when a user connects, instead of them having to install the package on their own.

Sweet, thanks for verifying!

Vadi wrote:We'll have a developer meeting next week so I'll pen this up.

Any updates?

Didn't meet last week, not enough people could make it. It'll be tabled again for next week.

We had the meeting today, we decided against adding MUME to the core - but we might offer a way you can add it later on ala out of band support. I'd really recommend looking into adding GMCP though, it is far easier to deal with and using it you can bootstrap your own MUD packages for Mudlet.

Vadi wrote:we decided against adding MUME to the core

I'm a little disappointed and I guess this does mean I will end up having to fork. Thanks for listening to my case!

I think it would be far wiser to add GMCP to your game as that would actually benefit both sides.