It's difficult to find much information about the protocol, but from what I've seen so far it appears to be less generic than MSDP.
For example, one of the comments Zugg made on his thread:
Quote
I've asked IRE to break down the Char.Vitals into individual attributes and they are working on it. For now you have to parse it yourself as OldGuy shows.
One of the things I like best about MSDP is the way it handles individual attributes. It allows each mud to provide whatever data it likes, and allows the client to retrieve whatever subset of that data it needs (without the need to retrieve any unwanted data).
However as long as GMCP is generic enough, it should be possible to transmit MSDP data through it, much like I did for ATCP. If so I will probably end up doing that for clients that don't support MSDP.
However as long as GMCP is generic enough, it should be possible to transmit MSDP data through it, much like I did for ATCP. If so I will probably end up doing that for clients that don't support MSDP.
GMCP supports arrays and associative arrays, so it might work to send something like this server side:
The nesting option is neat, and I think it might be wise to update MSDP to support nesting, or at least standardize how to display nested data so every MUD doesn't make up its own system. It should be possible to do something like:
MSDP_VAR "COORDINATES" MSDP_VAL MSDP_OPEN MSDP_VAR "X" MSDP_VAL "1" MSDP_VAR "Y" MSDP_VAL "2" MSDP_VAR "Z" MSDP_VAL "5" MSDP_CLOSE and tt++ could generate three events: #1 {COORDINATES[X]} = {1} #2 {COORDINATES[Y]} = {2} #3 {COORDINATES[Z]} {5}, or just one event: {COORDINATES} = {{X}{1}{Y}{2}{Z}{5}}, which could be saved directly as an associative array.
If you use a scripting language you could parse the msdp data and change it into: {"COORDINATES" : {"X" : "1", "Y" : "2", "Z" : "5"}} - or whatever format the scripting language uses.
MUDs wanting poor man's nesting could use the MSSP plaintext syntax:
MSDP_VAR "COORDINATES" MSDP_VAL "x\t1\ny\t2\nz\t5\n" which is compatible with GMCP and should be pretty easy to parse.
Careful! If you change those braces just a little bit, you'll be pretty close to re-inventing LPC data structures, and re-inventing the "mudmode" sockets they've used for 15 years or so…
Been a while since I worked with lpc, but parenthesis and brackets for associative arrays ([ ]) and braces for arrays ({ }) which is exactly the other way around.
Displaying nested MSDP in string notation looks somewhat like: COORDINATES {$X:1$Y:2$Z:5} which shouldn't be too hard to convert to JSON or LPC, though it's an unusual format.
Interesting that Lasher's considering going with MSDP - if Aardwolf does that, there's a much greater chance of the protocol gaining wider acceptance. I'd definitely like that, it would make my job a lot easier. However I do find it curious that he's considering using MSDP for his work and ATCP2/GMCP for (presumably) other plugin/script writers - I'd have thought it would be the other way around, as IMO the real strength of MSDP is that it allows each player to specify exactly what data they want, while ATCP* sends them the mud's recommended sequences, such as "Char.Vitals", etc.
* Still not sure how ATCP2 will handle this, perhaps it addresses this concern?
I don't think it'll come to that as Zugg is pretty quick when it comes to adding new protocols, and scripting MSDP in good old zmud should be a breeze compared to scripting GMCP. I think the main significance of this switch is that ATCP1 is history.
I think the main significance of this switch is that ATCP1 is history.
Wasn't that going to be the case anyway, though? I mean, we already knew that the IRE muds were moving over to ATCP2, and (as far as I understood it) the goal was that ATCP2 would be more generic, and therefore more easily adapted to other muds.
I admit I was expecting Aardwolf to jump from 102 to ATCP2, but from reading the blog it looks like it's not just the big mud and client developers ignoring everyone else - they seem to be ignoring each other as well, and all going back to doing their own thing.
MUSHclient, z/CMUD and TinTin++ support open protocols so this isn't really a big deal for them, but Mudlet refuses "for performance reasons" - although somewhat ironically it does support 102 and ATCP1. If Aardwolf does go for MSDP then hopefully Mudlet will add support for either open protocols or MSDP, which will make life easier for me…because my "ATCP as MSDP" hack, while fine for Mudlet, apparently causes CMUD to start spewing messages everywhere. And as I don't own a copy of CMUD, it's not really something I can easily track down.
Wasn't that going to be the case anyway, though? I mean, we already knew that the IRE muds were moving over to ATCP2, and (as far as I understood it) the goal was that ATCP2 would be more generic, and therefore more easily adapted to other muds.
From what I gathered Aardwolf switched from 102 to ATCP a while ago, but I could be mistaken.
I admit I was expecting Aardwolf to jump from 102 to ATCP2, but from reading the blog it looks like it's not just the big mud and client developers ignoring everyone else - they seem to be ignoring each other as well, and all going back to doing their own thing.
From what I gathered there might be another attempt with a smaller group, and if I'm lucky I won't be included as it'll probably mean more endless head butting. Truth is I learned from the whole mssp drama and had no expectations of mudstandards while having fun pushing tintin, vt100, 256 colors, msdp, and mssp.
Zugg added support to cmud and thinks it's very generic:
http://forums.zuggsoft.com/forums/viewto...
Some chatter over at the mush forums, Nick not sounding overly pleased:
http://www.mushclient.com/forum/bbshowpo...
Vadi messing around with mudlet:
http://forums.mudlet.org/viewtopic.php?f...
Scandum will probably spend an hour writing a JSON parser to convert the data to something that tintin can digest.
What the exact specification for the protocol is remains unclear for now.