We'll make it so you can select which modules should be merged and which should be replaced in their data, so your scripts could specify this, and work as intended.

Again, turning this into a switch is the wrong approach. Servers need to be able to trigger either refresh or update on an object.

Consider this real-life scenario:

1. We want to send group info–a very common need.
2. After we populate the group object, we need to be able to update the movement points of group members without having to re-send the whole group object at every move the group makes.
3. We also need to be able to trigger a 'redraw' of the group object in order to show that a member has left the group, e. g.

Yes, that's exactly what they'll be able to do - either refresh or update an update with this. You could empty out an object with an empty array or an object to do this. The group info could be specified as should be merging, so your scenario will work.

Any news in being included in Fedora packages ?

Haven't looked about getting it included. If it's anything like Debian, it would require befriending a Fedora maintainer to make it possible.

The important detail here is that the server needs to be able to flip that switch, not the client-side script. Only the server knows if the incoming data is a refresh or a partial update.

When I think about it some more, in my case (JS in HTML5) I will not need to empty out the object because I have a native parser that will recognize immediately that group.members[3] is an update to member #4 while group.members = [] is a redraw of all members in a group.

In your case, you may need to parse the key parameter a bit, but can you actually pull it off? If so, then you wouldn't need the switch anywhere.

The parser is a standard JSON parser, the way we transfer it to Lua data is what matters. The parser is separate - all it does is parse, and give us the new msg. We then choose if we merge it with existing data that's Lua-side or replace it.

I'm still in favour of cooperating with everyone on how this should be done, if the previous solution isn't good enough, so perhaps a separate thread for this topic should be made.

Right, so I think we have an opportunity here to take GMCP to a logical next level by setting a standard for the format of the 'object name' or 'key' parameter. This should basically enable any kind of partial update while keeping all existing implementations working.

I come from JS, which is also where JSON comes from. So here's how it would work in JS:

group […] //full refresh of group array
group.members[3] {…} //full refresh of member #4
//even better:
group.members['Ajax'] {…} //full refresh of member named Ajax, if members is a named array
group.members['Ajax'].mv 85 //update of Ajax's mv points

To build up on the above:

It's actually preferable to a GUI script to receive this:

//A:
group.members['Ajax'].mv 85
<<trigger update on element group.members['Ajax']>>
group.members['Bella'].mv 93
<<trigger update on element group.members['Bella']>>

vs. this:

//B:
<<turn merge on for group>>
group { members: [ 'Ajax': { mv: 85 }, 'Bella': { mv: 93 } ] }
<<trigger update on element group>>

In case A, the GUI will know to redraw just the movement points for Ajax, then Bella.

In case B, the GUI will need to redraw the whole group.

If you want to make a patch, I'd be happily committing it. It shouldn't be a lot of work for you as you're the one who came up with MSDP originally if I remember correctly.

I'm not sure if I can motivate myself to do so.

A generic telnet handler would be a solution. Raise events for unknown WILL WONT DO DONT and SB negotiations, and provide the content of the SB negotiation to the event. Then I could look into writing an MSDP parser in Lua that would work for both MC and Mudlet. In addition you'll have scripting support for every telnet protocol in existence, including MSSP, which can be used to automatically create a profile for the MUD and download an icon.

Alright. I'll see what I can do tomorrow.

I find myself noticing the Mudlet developers stating that Kavir's snippet allows fallback for MSDP through ATCP and because of this they should not add MSDP. While this was creatively thought out by Kavir and works pretty well, it actually hurts the development of MSDP, even though MSDP is now supported by 50+ muds? My guess is that you could combine the total number of muds which support GMCP and ATCP ( without Kavir's snipper ) and MSDP would still win out. Because of the fact that muds will continually add Kavir's snippet and that this number will only continue to grow, I would love to see it added to Mudlet.

We are actively pushing Mudlet to our players, as the client we used to support no longer is actively being developed and this client has unlimited potential.

SlothMUD recently went live with some of Kavir's code ( we had a great deal of this already implemented ) and already about 20% of our playerbase are using MSDP. One of our players even developed a beta version of TinyFugue with this protocol.

It certainly can't hurt, can it?

Enjoy,
Splork

You're probably right, but back when I wrote the snippet I had the chicken-and-egg problem - client developers didn't want to implement a protocol that no muds supported, while mud developers didn't want to implement a protocol that no clients supported. Open protocol support was an option for some clients, but Mudlet's response was "a firm no for performance reasons".

Although my protocol code was originally intended to be an MSDP snippet, it was really the concept of GUIs (rather than specifically MSDP) that I was trying to promote. I view Mudlet and MUSHclient as the two best candidates for muds wishing to offer custom GUIs, so I wanted my snippet to work with both of them.


I don't know what the current numbers are, but when I looked into it in October 2011 there were 25 muds that supported MSDP and 8 that supported GMCP. There were also 29 muds that supported ATCP, but 21 of those used it as a fallback for MSDP (they used my snippet) and 7 as a fallback for GMCP. ElephantMUD supported ATCP and ZMP, but every other mud used either MSDP or GMCP as its primary protocol.

According to Scandum's MSDP page there are now 29 muds that support MSDP, although I don't know how up to date that is. I do know that two of the "muds" on that list are actually public codebases, which other people have since downloaded as the basis for their own games.

I've added a generic telnet event sysTelnetEvent with 3 parameter where the third parameter isn't necessarily defined.

TELNET_EVENT: p1[253] p2[24] p3[]
TELNET_EVENT: p1[250] p2[24] p3[
]
TELNET_EVENT: p1[253] p2[31] p3[]
TELNET_EVENT: p1[253] p2[42] p3

TELNET_EVENT: p1[251] p2[69] p3[E]
TELNET_EVENT: p1[251] p2[70] p3[F]
TELNET_EVENT: p1[251] p2[93] p3[]]
TELNET_EVENT: p1[253] p2[200] p3[]

<MXP support enabled>
TELNET_EVENT: p1[253] p2[91] p3 p3[[]
TELNET_EVENT: p1[251] p2[90] p3[Z]
TELNET_EVENT: p1[251] p2[86] p3[V]

TELNET_EVENT: p1[250] p2[24] p3[
]
TELNET_EVENT: p1[250] p2[200] p3[MSDP.SERVER_ID God Wars II]
TELNET_EVENT: p1[250] p2[91] p3[[]
TELNET_EVENT: p1[250] p2[200] p3[MSDP.HOTKEY 1 ]
TELNET_EVENT: p1[250] p2[200] p3[MSDP.HOTKEY 2 ]
TELNET_EVENT: p1[250] p2[200] p3[MSDP.HOTKEY 3 ]
TELNET_EVENT: p1[250] p2[200] p3[MSDP.HOTKEY 4 ]
TELNET_EVENT: p1[250] p2[200] p3[MSDP.HOTKEY 5 ]
TELNET_EVENT: p1[250] p2[200] p3[MSDP.HOTKEY 6 ]
TELNET_EVENT: p1[250] p2[200] p3[MSDP.HOTKEY 7 ]
TELNET_EVENT: p1[250] p2[200] p3[MSDP.HOTKEY 8 ]
TELNET_EVENT: p1[250] p2[200] p3[MSDP.HOTKEY 9 ]
TELNET_EVENT: p1[250] p2[200] p3[MSDP.HOTKEY 10 ]
TELNET_EVENT: p1[250] p2[200] p3[MSDP.HOTKEY 11 ]
TELNET_EVENT: p1[250] p2[200] p3[MSDP.HOTKEY 12 ]

Is this enough?

Well, I'd still like direct C support better than Lua, but I agree that open protocol support is necessary as the community is growing smaller. We should join our forces wherever we can.

You can use the sendSocket(data) function to send unfiltered data directly to the server. All other things should be covered by the API. The code for open protocol support is already in git and I'll release a new Mudlet-2.1 windows binary later tonight.
Let me know if you need anything else for open protocol support.

Following example script demonstrates primitive MSDP support:

TN_IAC = 255
TN_WILL = 251
TN_DO = 253
TN_SB = 250
TN_SE = 240
TN_MSDP = 69

MSDP_VAR         =  1
MSDP_VAL         =  2
MSDP_TABLE_OPEN  =  3
MSDP_TABLE_CLOSE =  4
MSDP_ARRAY_OPEN  =  5
MSDP_ARRAY_CLOSE =  6

MSDP_GOT_ENABLED = false

function MSDPHandler( e, p1, p2, p3 )
	if not p1 then p1 = "empty" end
	if not p2 then p2 = "empty" end
	if not p3 then p3 = "empty" end
	echo("TELNET_EVENT: p1["..p1.."] p2["..p2.."] p3["..p3.."]\n")
	
	if p1 == TN_WILL and p2 == TN_MSDP and not MSDP_GOT_ENABLED then
		MSDP_GOT_ENABLED = true
		echo("\n<MSDP enabled>\n")
		sendSocket( string.char( TN_IAC, TN_DO, TN_MSDP ) ) – IAC DO MSDP
		getMSDPVars()
	end
end



function getMSDPVars()
	–IAC   SB MSDP MSDP_VAR "LIST" MSDP_VAL "COMMANDS" IAC SE
	local msg = string.char( TN_IAC, TN_SB, TN_MSDP, MSDP_VAR ) .. "LIST" ..string.char( MSDP_VAL ) .. "COMMANDS" .. string.char( TN_IAC, TN_SE )
	sendSocket( msg ) 
end

addSupportedTelnetOption( TN_MSDP ) – 69 announce support for MSDP
registerAnonymousEventHandler("sysTelnetEvent", "MSDPHandler")

As excited as I am to see open protocol support in Mudlet, I don't think it's likely to see much use for MSDP. Most muds using MSDP have installed my snippet, which means they also support ATCP as a fallback option - and ATCP automatically handles negotiation and triggers events for you, as well as giving you access to the autoinstaller so that players don't have to manually install the script.

1. I'm primarily interested in what is needed to have full open protocol support in Mudlet. Is this enough or do we need anything else?

2. I remember Scandum from the failed Mudstandards effort. He is the one who developed MSDP and I think it's best if he does a complete *correct* reference implementation of MSDP in Lua that both Mushclient and Mudlet can use as well as any other client in the future. He can add the Mudlet package autoinstaller to MSDP if he wants to using installPackage(), uninstallPackage() and the downloadFile() functions. Personally, I think that Nick Gammon's GMCP is superior to MSDP, but that's just my personal opinion. If the majority of MUDs consider MSDP easier to support than GMCP we shouldn't be a show stopper and support MSDP or any other new protocol - or at least give people the means to do so themselves. If he comes up with a useable MSDP implementaion I'll gladly install it as a default package and then every Mudlet user can make use of MSDP out of the box.

3. Your MSDP over ATCP protocol snippet is a great example of what is possible if people start to work together across game and client boundaries. I hope that open protocol support will produce more beauties like this in the future.