06 Apr, 2010, KaVir wrote in the 1st comment:
Votes: 0
I added ZMP today, as one of my players has written a TinTin++ promptbar and it was mentioned to me in the past that ZMP was a good solution for this sort of thing. There don't seem to be many options though, and I'm having trouble finding other muds to make comparisons with.

For the time being I've added zmp.output and zmp.prompt options, which work like this:

Quote
> zmp.output name
ZMP SEND zmp.output (name)
ZMP RECV zmp.output (KaVir)

> zmp.output brawn
ZMP SEND zmp.output (brawn)
ZMP RECV zmp.output (191)

> zmp.output power:blood legacy
ZMP SEND zmp.output (power:blood legacy)
ZMP RECV zmp.output (7)

> zmp.prompt $h/$H
ZMP SEND zmp.prompt ($h/$H)
ZMP RECV zmp.prompt (3350/3350)

Presumably these should really be part of a package? The documentation doesn't seem to be very clear on the matter.

I'm also thinking of adding a zmp.observe command, which tells the mud to automatically send a zmp.output every time the specified variable changes, as this would remove the need for the promptbar to keep spamming the mud with data requests. I don't want clients observing hundreds of things though, so it'll need to be limited somehow.

Anyone else done this already?
06 Apr, 2010, Scandum wrote in the 2nd comment:
Votes: 0
Might be easier using MSDP which is intended to be more open ended and work with client side interfaces.

What you do is send variables to the mud client, and you (ideally) only resend the variables as they change. So that'd be pretty much the observe functionality you are mentioning.

The standardization approach is the same as with MSSP, generic variables are agreed upon and documented centrally, and mud specific implementations should borrow as much as they can and document decentralized. The protocol is still pretty open due to lack of interest.
06 Apr, 2010, Scandum wrote in the 3rd comment:
Votes: 0
I just had your player asking for assistance on the tt++ forum, so I'll elaborate a bit further about how TinTin++ handles this.

MSDP strictly defines variables and values, and because of this tt++ can trigger an event for each variable/value pair, and provide the variable and value for the user to use. ZMP has an open ended package approach, and as such tt++ allows creating separate events for each package, but specific package parsing is left to the user, which depending on the package will be either easy or quite difficult. I'm not planning to hardcode ZMP package support, or MSDP support for that matter.

So the big distinction here is that ZMP is a server–>client_developer protocol, while MSDP is more of a server–>client_user protocol.
06 Apr, 2010, KaVir wrote in the 4th comment:
Votes: 0
MSDP looks pretty simple to add, but as far as I can see it's only one-way. How would the client request which variables it wanted? I guess I could use ZMP for the request and MSDP for the response, but that doesn't seem like a very satisfactory solution.

There's also the question of support. Do any clients other than TinTin++ support MSDP?
06 Apr, 2010, Scandum wrote in the 5th comment:
Votes: 0
I still need to document two-way communication in the MSDP specification.

I believe the proper way would be for the server to send: IAC WILL MSDP (I can send data) + IAC DO MSDP (I can receive data). Then the client responds with IAC DO MSDP (I can receive data) and IAC WILL MSDP (I can send data). Is that correct?

For requesting variables the MSDP array format would be ideal: IAC SB MSDP VAR "UPDATE" VAL "BLI" VAL "BLA" VAL "BLO" IAC SE - Though I think a more descriptive name than UPDATE is needed. I've had close to no feedback, so I'm pretty open minded about the variable set.

Regarding clients, TT++ and JMUD support MSDP, and clients like mushclient and zmud can script a telnet handler.
06 Apr, 2010, KaVir wrote in the 6th comment:
Votes: 0
Scandum said:
I believe the proper way would be for the server to send: IAC WILL MSDP (I can send data) + IAC DO MSDP (I can receive data).

Surely only one or the other is needed? I think the server sending IAC WILL MSDP is fine, the way you've got it now.

*** CLIENT CONNECTS TO SERVER ***

Server: IAC WILL MSDP

Client: IAC DO MSDP

Then the client could do something like:

Client: IAC SB MSDP MSDP_VAR "HEALTH" IAC SE

And the server could respond with something like:

Server: IAC SB MSDP MSDP_VAR "HEALTH" MSDP_VAL "500" IAC SE

Thus sending a MSDP_VAR without a MSDP_VAL could be treated as a "get" request. In theory the server could even use this to retrieve client variables, just as the client could use it to set server variables, assuming both sides agreed (for example I might allow clients to set config options this way).

I could then implement my observer as a special variable:

Client: IAC SB MSDP MSDP_VAR "OBSERVE" MSDP_VAL "HEALTH" MSDP_VAL "MANA" MSDP_VAL "MOVEMENT" IAC SE

But this wouldn't need to be part of the standard.
06 Apr, 2010, KaVir wrote in the 7th comment:
Votes: 0
KaVir said:
Thus sending a MSDP_VAR without a MSDP_VAL could be treated as a "get" request.

I did this to try it out, and it works fine.

I've not implemented any of the generic variables. I assume these are optional? I guess I could try and best-fit them.

Right now I just pass the MSDP_VAR into the character's GetText() method and return the result, which lets me query things such as "HEALTH". It also means my variables are case insensitive.
07 Apr, 2010, Scandum wrote in the 8th comment:
Votes: 0
KaVir said:
Surely only one or the other is needed? I think the server sending IAC WILL MSDP is fine, the way you've got it now.

I think it would be alright if MSDP is redefined to be a two way street by default.. I don't think it's typical telnet behavior though, I'm quite sure NEW ENVIRON needs to be negotiated for each side. Syntactically it'd be difficult as well, since IAC WILL MSDP would have the same meaning (I'll send and accept sub-negotiations) as IAC DO MSDP. There will also be cases where only the server sends MSDP sub-negotiations, so any sub-negotiations from the client would be a waste of bandwidth.

KaVir said:
Then the client could do something like:

Client: IAC SB MSDP MSDP_VAR "HEALTH" IAC SE

And the server could respond with something like:

Server: IAC SB MSDP MSDP_VAR "HEALTH" MSDP_VAL "500" IAC SE

Thus sending a MSDP_VAR without a MSDP_VAL could be treated as a "get" request. In theory the server could even use this to retrieve client variables, just as the client could use it to set server variables, assuming both sides agreed (for example I might allow clients to set config options this way).

I think it'd be easier to use a SEND variable (that's how it's named in the NEW ENVIRON rfc) which asks the other side to send the requested variables, for example using the array format:

IAC SB MSDP VAR "SEND" VAL "HEALTH" VAL "MANA" VAL "ETC" IAC SE

I think it's a bad idea to go the no value route, as IAC SB MSDP VAR "NAME" IAC SE is (in the current tt++ implementation) identical to IAC SB MSDP VAR "NAME" VAL IAC SE, the latter meaning to set the variable NAME to ""

KaVir said:
I could then implement my observer as a special variable:

Client: IAC SB MSDP MSDP_VAR "OBSERVE" MSDP_VAL "HEALTH" MSDP_VAL "MANA" MSDP_VAL "MOVEMENT" IAC SE

But this wouldn't need to be part of the standard.

I do like the concept, but I'm not sure if OBSERVE is the most descriptive variable name given how TELNET typically does the naming. How about "REPORT" - as in to tell the server to start reporting the provided list of variables? An empty value (IAC SB MSDP VAR "REPORT" VAL IAC SE) could be interpreted to report on all available variables.
07 Apr, 2010, David Haley wrote in the 9th comment:
Votes: 0
So, just out of curiosity, if we're speaking of a new protocol, or even significant modifications to an existing (albeit basically unused) protocol, shouldn't that be discussed elsewhere? Like, mudstandards? :wink:
07 Apr, 2010, KaVir wrote in the 10th comment:
Votes: 0
Scandum said:
I think it would be alright if MSDP is redefined to be a two way street by default.. I don't think it's typical telnet behavior though,

Well ATCP already sends messages in both directions, so you could use that as a reference. In the case of ATCP the server sends DO, but in this case I think WILL is more appropriate, as the server is doing most of the work.

Scandum said:
I think it's a bad idea to go the no value route, as IAC SB MSDP VAR "NAME" IAC SE is (in the current tt++ implementation) identical to IAC SB MSDP VAR "NAME" VAL IAC SE, the latter meaning to set the variable NAME to ""

Okay…well I guess using something like "SEND" (as a string) wouldn't so different to the OBSERVE/REPORT scenario. It's just another variable.

Scandum said:
I do like the concept, but I'm not sure if OBSERVE is the most descriptive variable name given how TELNET typically does the naming.

It was more a reference to the observer pattern. But I don't think it needs to be part of the standard anyway - as far as MSDP is concerned, it's just another message.

Thus I might personally decide to add support for:

SEND: Tell the server to send the specified variable/s once.

OBSERVE: Tell the server to send the specified variable/s every time it changes.

INPUT: Tell the server to parse the specified variable/s as input.

COMMANDS: Tell the server to return these four options.

However these are already covered by the existing protocol, just not explicitly defined, so the document wouldn't need to be changed. If you want them to be added to the standard you could perhaps add a section for "Command" variables.

David Haley said:
So, just out of curiosity, if we're speaking of a new protocol, or even significant modifications to an existing (albeit basically unused) protocol, shouldn't that be discussed elsewhere? Like, mudstandards?

Probably, but I can already guess what sort of response it would get. The fact is that I really want something like ZMP or MSDP for my plugin-writing players, and it looks like MSDP is going to be easier for them to use. The protocol is more likely to be taken seriously on MudStandards if it's already supported by an operational mud and a major client.
0.0/10