11 Jul, 2010, Scandum wrote in the 1st comment:
Votes: 0
So it appears work on this puppy continued behind the scenes after things went silent on mud standards.

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.
11 Jul, 2010, KaVir wrote in the 2nd comment:
Votes: 0
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.
11 Jul, 2010, Scandum wrote in the 3rd comment:
Votes: 0
Forgot about the IRE link:

http://www.ironrealms.com/gmcp-doc

KaVir said:
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:

MSDP { "HEALTH" : "24", "HEALTH_MAX" : "42" }

And client side:

MSDP { "REPORT": [ "HEALTH", "HEALTH_MAX", "MANA", "MANA_MAX" ] }


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.
12 Jul, 2010, quixadhal wrote in the 4th comment:
Votes: 0
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…
12 Jul, 2010, Scandum wrote in the 5th comment:
Votes: 0
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.
13 Jul, 2010, Scandum wrote in the 6th comment:
Votes: 0
13 Jul, 2010, KaVir wrote in the 7th comment:
Votes: 0
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?
13 Jul, 2010, Scandum wrote in the 8th comment:
Votes: 0
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.
13 Jul, 2010, KaVir wrote in the 9th comment:
Votes: 0
Quote
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.
14 Jul, 2010, Scandum wrote in the 10th comment:
Votes: 0
KaVir said:
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.

KaVir said:
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.
0.0/10