Hello!

Mudlet 2.0 is now available. This update adds a 2D/3D mapper, GMCP, MXP and a host of other features - see the full overview here.

Cheers and a Happy 2013!

Excellent work!

downloaded it.. still has the mccp issues that previous versions had….

Sorry about that - as far as we're aware given the feedback, there are no problems with it. If you could bring it up again to us, it'd be appreciated.

Congrats on the release. It's definitely a step in the right direction, and I'm sure it will only get better.

Our ambitious Mudlet GUI developer should have filed several issues with GMCP. If not, here they are again:

* Escaped special characters like " ' , inside GMCP chat messages are not recognized.

* Lack of support for partial updates to GMCP objects is holding us back.

I also have a player who has had mixed success with the new auto-map tool. I can report back when and if I learn specifics.

Is there MSDP / open telnet support in the planning?

I don't believe they have.

* Escaped special characters like " ' , inside GMCP chat messages are not recognized.

There's no MUD server that I know of can send this data - so if you could provide one, we'll be glad to look at this.

* Lack of support for partial updates to GMCP objects is holding us back.

Mudlet does do partial updates - and in fact, at the start, did partial updates on all items. However some MUDs wanted certain fields to be partial updates, certain fields to be overwritten - see the discussion of that here. At the moment, I believe we set it to merge the Char.Status table (which typically contains vitals, so you can do partial updates), while overwriting the rest. If your MUD requires it any differently, get in touch with us on our forums, and we'll work something out.

Mudlet supports Aardwoolf's 102 channel, ATCP and GMCP - we don't think MSDP is necessary to add at the moment. KaVir has made a code snippet that can relay MSDP over ATCP as well, if that'll help you (and I think he mentioned a good deal of MUDs using MSDP provide ATCP as a fallback).

bedlam.gotdns.com:9000

We're just looking for standard JSON escaping compliance, where we can send something like: { channel: 'gossip', message: 'The big brown fox\'s box' }



GMCP is very poorly documented, and there's nothing I could find on partial updates, yet it seems like 90% of the point of sending data in an object so it won't hurt to extend it. I'm adding support for partial updates to my HTML5 app, and the most flexible way I can think of adding a reset/update option is to always respect an empty object message. So, e. g. if "Char.Status" already exists and I get Char.Status = { something }, then that's a signal for a partial update. If I get Char.Status={}, I would set the object to null (reset), and the next Char.Status = { something } will perform a full update.

That would break compatibility existing GMCP users, who for example send lists of data as arrays - with merging all the time, the list would not stay fresh and just keep adding items.

I'm also wary about assigning a special meaning to {}.

If the object holds an array of objects, the way to update it would be to send, e. g:

group.members[3] = { hp: 320 } // update fourth group member's hp to 320

So I don't see a problem here.



We either need to specify a message signaling a refresh, or we would need, for every message, an extra something specifying whether it's a merge or a refresh. Option A seems a bit more efficient. And of all the messages signaling a refresh, emptying the object seems the most natural to me. If you're a purist, you can ask for Char.Status = null. But that's a bit harder to code on the server side, for no real reason.

Anyway, this is all uncharted waters, that should have been charted a long time ago. It's up to you what you want to do about it. I know that for my custom clients I'm going to go ahead with a refresh signal of the sort I described.

group.members[3] = { hp: 320 } // update fourth group member's hp to 320

You're implying that others will change their ways to do this, though? That's pretty specific, I believe by default everyone made the assumption that the keys would be replaced and that's how it went in. Unfortunately the discussion boards since then went down, so we're left dealing with existing implementations.

@refresh: well, feel free. I don't think it's a good solution myself. Client-side, your decision would be worked around by treating Mudlets gmcp data as temporary and having scripts in the client deal with the merging or setting as they wish (it'd requite all Mudlet users having that compatibility layer - something that's easy to manage as Mudlet can auto-install scripts from MUDs on connect).

I think if anything, the people here would be best suited for working out a solution for this problem, so perhaps a separate thread for this would be good.

I'm only implying that this is how it should be done. That said, I'm willing to bet that if a major client like Mudlet started supporting this, any mud that sends info in an array will be very tempted to overhaul their code and make its output potentially hundreds of times leaner.

Existing implementations of a poorly documented 'protocol' should not deter us from finding better ways of doing things.



I'm not the person developing our Mudlet GUI but my guess is he'll continue to rely on the capabilities of the built-in GMCP parser. I just want to convey that, in my book, 'supports partial updates' means support for both full and partial, and not that some object is hard-coded selectively with 'merge on'. It doesn't have to be an either/or situation, and we don't all have to be married to the fact that GMCP has gaping holes in it.



That's very true, at least for the people who come here looking to work out and share solutions :).

As far as trend-setting goes, whatever you decide to do is going to be more influential than what I do for my dedicated clients, obviously. I just thought it might be useful as a point of interest.

The only way you'll set a trend is by breaking compatibility - and we don't want to inconvenience our MUD users, who has the final result and for whom we're doing this. I don't believe we'll doing that.

Yeah, it has problems for certain, like this ambiguity. I'm willing to work out the best solution to make it happen. Mudlet got to where it is today with GMCP because that's how we in cooperation with MUD admins that used it and communicated with us worked out this solution that - at the moment - works for all users.

That would work with TinTin++, and it also allows adding to an existing table if the user wants this. Other clients that operate at a higher level, shielding the variable update process from the end user, might have trouble handling this properly.

I don't see how what I've suggested breaks any existing compatibility.

Changing how GMCP updates work on the variable to be all merges again will break compatibility, see the discussion we've had on our forums where we at the start merged everything as that seemed like a better idea.

I just checked it out, and it doesn't seem to be a problem, the message was received and displayed in the tabbed chat fine. Here's the data:

comm = {
    channel = {
      player = "Demise",
      msg = "any one got some armor they don't need",
      chan = "gossip"
    }
  }

If a server implementation supports both merge and refresh, it can declare this in a new message, or just by explicitly initializing its objects as empty ones at the start of a session. At this time, you will know whether to use new or legacy parsing logic. So that's not very hard to phase in, if there's a will.

As far as I know, clients like MUSHClient and CMUD default to merging. So, the bigger picture here is that we don't really have compatibility. As someone who maintains a server, I don't really care whether all users of Mudlet agreed that refresh is preferable to merge. I do (kind of) care about implementing one logic for GMCP a-la Mudlet and another one for GMCP a-la CMUD.

Also, I think we can all agree that supporting both merge and refresh is the real prize here. As someone who builds UI's for a living, I would not even look at a protocol that is incapable of telling me whether something in the server state changed partially or completely.

So, if you've decided that GMCP will be your primary supported data protocol, why not put all your chips in?

You're right. We don't seem to have this issue ATM. I'm not sure if it got sorted out on our end or in a recent Mudlet update. Flag this as resolved.