Works for me. I just want to make sure the behaviour is clearly defined.

By the way, feedback from my script-writing player has been very positive. He said the REPORT option has allowed him to remove around 50 lines from his script, as he could throw out all of the timer-based update stuff.

He did mention that variables with spaces need to be put inside braces, though, and it made me wonder if some clients might not even permit such variable names.

Thinking about it I'm quite sure several clients won't, not to mention it looks ugly in tt++. Replacing the space with an underscore should work for all c-like scripting languages, so I'm going to change it to:

REPORTABLE_VARIABLES and CONFIGURABLE_VARIABLES, and update all other variables containing spaces to use underscores.

Think we might need an IAC SB MSDP VAR "LIST" VAL "LISTS" IAC SE option to list all available lists? Not sure if there's a better list name.

I've added it, I think it makes sense.

I checked out the LISTS option, and getting an unusual response

msdp_list lists
RCVD IAC SB MSDP
IAC SB MSDP (VAR LISTS                VAL COMMANDS)
IAC SB MSDP (VAR PROTOCOLS            VAL VARIABLES)
IAC SB MSDP IAC SE

This should be:

msdp_list lists
RCVD IAC SB MSDP
IAC SB MSDP (VAR LISTS                VAL COMMANDS)
IAC SB MSDP (VAR LISTS                VAL PROTOCOLS
IAC SB MSDP (VAR LISTS                VAL VARIABLES)
IAC SB MSDP IAC SE

Not sure if the problem is on my end or your end. The mud should send: IAC SB MSDP VAR "LISTS" VAL "COMMANDS" VAL "PROTOCOLS" VAL "VARIABLES" IAC SE. TinTin++ will remember the variable and create a separate event for each value in the array.

I also noticed you use HEALTH_MAX rather than MAX_HEALTH (as in the spec). For organizing purposes it's probably better to use HEALTH_MAX, so I'll change the specification in that regard to put MAX last. I'll also change SERVER_TIME and MUD_TIME to TIME_MUD and TIME_SERVER so it's easier to alphabetically sort it.

Also not too sure about going through with the PROTOCOLS list as I'm leaning toward hardwiring MVTS into TinTin++, which should be easier to support for other clients and MUDs as it uses TTYPE, and does more or less the same thing. I can start a thread on MVTS if people are interested in fleshing it out further. Normal clients don't really need MVTS as their client name can be used to determine terminal emulation support, but it'll be a fun categorization project.

Probably mine - I only added support for sending multiple variables at a time yesterday, so it's probably treating LISTS as var/val/var/val. I may have done the same with some of the others too, I'll go over them again in a few hours and double check.

I've made some other fixes too. The server no longer sends a newline or prompt after a subnegotiation sequence, meaning you can now transfer data in both directions without any visible effect on the screen. The server now also switches off MSDP before a reboot, and renegotiates again afterwards. My statistics page also lists how many MSDP users there are (currently very low, as right now just a few people are experimenting with it - once there are some working scripts and plugins I expect the number to rise considerably).

I still need to do more work on the server end though. I'm going to change the REPORT from an instant response to a dirty flag, so that it doesn't send the variables one at a time (right now it only sends them together when they're initially requested). There are a few other things I should clean up as well.


I'm not dead-set on any particular naming convention, and I've still got more variables to add, but I found it easier to organise the variables that way at the time.


I don't really mind either way, it's only a few extra lines of code to list the protocols with MSDP.

You mean sending out an update of all altered variables once a second or so? That's the most efficient way to go about it as far as I can tell.


I think I'll stick with HEALTH_MAX and suffix notation in general.


The problem for me is that I don't want to hard code anything in MSDP. Also, it just struck me that it should be preferable to use CONFIGURABLE_VARIABLES to communicate the enabling of ANSI, 256 colors, etc. Knowing the other supports something is of less importance to knowing if the user actually wants the support enabled. So I'm heavily leaning toward dropping PROTOCOLS and suggest MUDs implement CONFIGURABLE_VARIABLES instead for protocols that can't be enabled using TELNET.

I'll probably check every 10th of a second, immediately after polling for descriptor activity, otherwise there'll be a small delay after input before bars and such update. It'll check if the dirty flag is set before updating anything, so it shouldn't be much less efficient.


Hrm that's a good point - even if you didn't explicitly include them in the spec, they'd be prime candidates for inclusion as CONFIGURABLE_VARIABLES. I'd already planned to handle MSP this way, so that players could download a self-extracting zip containing a client with plugins preinstalled and a soundpack, and one of the plugins could automatically switch on MSP for the player.

What are the rules for setting CONFIGURABLE_VARIABLES? Must the second parameter be an integer, or can it also be a string? Supposing I want to let people configure their gender (so that it's possible to have a "character creation" plugin). Can I say that the valid options are NEUTER, MALE and FEMALE, or do they have to be 0, 1 and 2? Or are config options always boolean, so that I must instead have a separate variable for each gender?

Option 1: Gender is a string:

IAC SB MSDP MSDP_VAR "GENDER" MSDP_VAL "NEUTER" IAC SE
IAC SB MSDP MSDP_VAR "GENDER" MSDP_VAL "MALE" IAC SE
IAC SB MSDP MSDP_VAR "GENDER" MSDP_VAL "FEMALE" IAC SE

Option 2: Gender is an integer:

IAC SB MSDP MSDP_VAR "GENDER" MSDP_VAL "0" IAC SE
IAC SB MSDP MSDP_VAR "GENDER" MSDP_VAL "1" IAC SE
IAC SB MSDP MSDP_VAR "GENDER" MSDP_VAL "2" IAC SE

Option 3: Each gender is a variable:

IAC SB MSDP MSDP_VAR "GENDER_NEUTER" MSDP_VAL "1" IAC SE
IAC SB MSDP MSDP_VAR "GENDER_MALE" MSDP_VAL "1" IAC SE
IAC SB MSDP MSDP_VAR "GENDER_FEMALE" MSDP_VAL "1" IAC SE

I think I personally prefer the first option, but that would require a way to list the possible arguments. For example:

Client: IAC SB MSDP MSDP_VAR "SEND" MSDP_VAL "GENDER" IAC SE
Server: IAC SB MSDP MSDP_VAR "GENDER" MSDP_VAL "NEUTER" IAC SE
Client: IAC SB MSDP MSDP_VAR "QUERY" MSDP_VAL "GENDER" IAC SE
Server: IAC SB MSDP MSDP_VAR "QUERY" MSDP_VAL "NEUTER" MSDP_VAL "MALE" MSDP_VAL "FEMALE" IAC SE
Client: IAC SB MSDP MSDP_VAR "GENDER" MSDP_VAL "MALE" IAC SE

It would then be up to the client to remember its last query. Not sure if I like that though. Maybe it should be CONFIGURABLE_PARAMETERS instead, and perhaps the first value should also be the variable name…

Client: IAC SB MSDP MSDP_VAR "CONFIGURABLE_PARAMETERS" MSDP_VAL "GENDER" IAC SE
Server: IAC SB MSDP MSDP_VAR "CONFIGURABLE_PARAMETERS" MSDP_VAL "GENDER" MSDP_VAL "NEUTER" MSDP_VAL "MALE" MSDP_VAL "FEMALE" IAC SE

Not sure I like that either, though.

I'll split up the variables in reportable and configurable, and add a list of suggested Protocol variables. Probably best to negotiate MSP using the MSP TELOPT though?

In MSSP the specification defines what the valid arguments are, and I think the same should go for MSDP. For protocols a boolean ("0" or "1") will typically suffice, but in the case of gender, using MSSP as a guideline, I'd define the following in a specification extension myself:

GENDER             Male, Female, Neuter

If you want to go the boolean route you could have LIST CONFIGURABLE_VARIABLES return GENDER_MALE GENDER_FEMALE which could be used as toggles to create males, females, neuters, and hermaphrodites.

I guess there's some benefit to communicating all variables and their values, but it would require nesting to do it properly.

The problem is that while MUSHclient supports the MSP sound triggers, it doesn't support the negotiation (at least not with the latest stable release), and as far as I know the same may be true for other clients as well. Even for clients that support the negotiation, the player may not have downloaded the soundpack - perhaps they don't even want sound - so I don't want to force them to accept the triggers.

Thus I'd need an option for switching sound on even if negotiation failed, and an option for switching sound off even if negotiation succeeded. So in the end I decided it was easier just to make it a toggled option, and ignore the negotiation entirely. I guess I could use it to recommend the soundpack to new players (i.e., send them some sort of hint if their client responds to the handshake), but it barely seems worth the effort.


Okay, so just cover it on the website referenced via the SPECIFICATION variable? I suppose that makes sense, it's certainly easier (for both the server developer and client developer) than having to send messages back and forth for each variable just to work out what you're allowed to send.

Otherwise it starts raising other questions, like what exactly the variable represents - but it's going to start making the protocol a lot more complex if each variable needs to pass back a description upon request.


Then I suggest we leave that up to the SPECIFICATION - just mention that the mud should provide any necessary instructions and documentation on its website, with the URL for that website returned by the SPECIFICATION variable.

It seems kind of odd to me to offer a plugin using MSDP to enable MSP in mushclient if you could have the same plugin use the MSP TELOPT's handshake. Then again, if you provide an MSDP interface to your game's configuration command, and it provides an option to toggle MSP, it makes sense to add it.


Indeed. I think that'll be preferable to making the protocol more complex.


I'll make a specific mention of it. The idea is to link all extended specifications from the main spec's page, so developers can easily borrow from each other.

The problem is that the handshake is generic - if I switched MSP on after establishing a handshake, then everyone using a client that fully supported MSP would also automatically switch on the sound triggers, and I believe some clients give a warning beep or message if the sound files aren't found.

But yes, I already have an 'MSP' config option, so if I allow config options to be toggled through MSDP then it would also allow MSP to be switched on and off. I think this actually makes sense if the plugin that switches MSP on is preinstalled into a downloadable package that also comes with the soundpack.

My mud now has 90 active characters (from 25 different IP addresses) using MSDP.

I have a MUSHclient plugin which uses it to draw energy bars and graphical maps, but these options are of no use when playing other muds - so for now I only activate the plugin if the mud supports MSDP. This is okay for the time being, as no other muds support it, but it could be a problem in the future.

I'm also running into the occasional issue with players using old versions of the plugin, either because they forgot to download something, or because they saved the new plugin in the wrong place (and are therefore using the wrong one).

So I've been thinking of adding an extra option - some means of identification, rather like ZMP uses. This would be initiated by the client after a handshake, and the server should then respond with an identification of its own. Eg:

Server: IAC WILL MSDP
Client: IAC DO MSDP
Client: IAC SB MSDP MSDP_VAR "ID" MSDP_VAL "GW2 MUSHclient plugin 1.6" IAC SE
Server: IAC SB MSDP MSDP_VAR "ID" MSDP_VAL "God Wars II" IAC SE

The client plugin could then delay its activation until "ID" is "God Wars II", and the server could record the fact that the player is using "GW2 MUSHclient plugin 1.6" - this would allow me to see which versions of the plugin the players are using, and incorporate it into a dynamic help file for troubleshooting.

ID seems like a somewhat obscure variable name to me, how about SERVER_NAME and PLUGIN_NAME?

Would be cleaner if those variables are requested with the SEND command, and alternatively MSSP can be used to get the server name.

This thread gets the Koron Seal of Approval. It's nice to see people working together like this. Yay for actual community efforts. :biggrin:

Could do, although it's more likely to be overlooked if its clumped together with the regular variables. I was thinking more of something along the lines of the zmp.ident command, as a sort of "recommended" followup to the handshake.


I don't want to mix it with MSSP - I'd like to keep this all within the same protocol.

Adding an extra SEND to the plugin would be easy enough, but I'd rather not get the server to request the version from the plugin, as nobody seems to bother adding that support. Instead I'd probably just get the plugin to offer its version, as the server will just ignore it if it doesn't accept that variable.

So…

Server: IAC WILL MSDP
Client: IAC DO MSDP

Client: IAC SB MSDP MSDP_VAR "SEND" MSDP_VAL "SERVER_NAME" IAC SE
Server: IAC SB MSDP MSDP_VAR "SERVER_NAME" MSDP_VAL "God Wars II" IAC SE

Client: IAC SB MSDP MSDP_VAR "PLUGIN_NAME" MSDP_VAL "GW2 MUSHclient plugin 1.6" IAC SE

ACCOUNT_NAME, CHARACTER_NAME, SERVER_NAME, PLUGIN_NAME…perhaps these should be the other way around? NAME_ACCOUNT, NAME_CHARACTER, NAME_SERVER, NAME_PLUGIN. That would be more consistant with the other variables, although I'm not sure that they should be clumped together like that.

But maybe server and plugin would be better named IDENTIFIER_SERVER and IDENTIFIER_PLUGIN? After all, they're not just names (and in theory might not even contain names). If two muds had the same name, they'd need to send different IDENTIFIER_SERVER values. In theory you might even have different plugins for different ports of the same mud, in which case one might send an IDENTIFIER_SERVER of "God Wars II" and the other "God Wars II Building Port". Likewise, the IDENTIFIER_PLUGIN would change each time a new version was released, so that the mud could see which versions people were using.

Thinking about it, the client would need to wait until it received the server identifier before offering the plugin identifier. Otherwise you might have two different MSDP plugins for completely different muds, and they'd both offer their identifiers, which could confuse the server. Having said that, you might well have multiple valid plugins for the same mud, so the server might need to keep track of more than one. I guess the server could in theory send multiple identifiers too (for example a ROM derivative with its own plugins might send its server name and "ROM", indicating that standard ROM plugins work for it as well). But perhaps this is getting overly complex…

For the time being, all I really care about is:

1) Ensuring that my plugin doesn't activate when people are playing other muds.

2) Being able to check which version of my plugin players are using.

On a related note, I've also added psuedo-MSDP support through ATCP. When the client connects, the server negotiates ATCP along with the other protocols:

Server: IAC DO ATCP
Client: IAC WILL ATCP

After successfully establishing a handshake, the client may send the following message to the server:

Client: IAC SB ATCP "MSDP" IAC SE

The client can then make MSDP requests through the ATCP channel, with the following differences:

1) Only one variable can be sent within each subnegotiation sequence.

2) There is no MSDP_VAR before the variable name.

3) Instead of MSDP_VAL, each value is preceded by a space. It's up to the plugin to work out whether this variable really has multiple values, or just has spaces in its value.

4) Returned variables are prefixed with "MSDP.".

Thus this…

Client: IAC SB MSDP MSDP_VAR "SEND" MSDP_VAL "HEALTH" MSDP_VAL "MANA" IAC SE
Server: IAC SB MSDP MSDP_VAR "HEALTH" MSDP_VAL "500" MSDP_VAR "MANA" MSDP_VAL "100" IAC SE

Becomes…

Client: IAC SB ATCP "SEND HEALTH MANA" IAC SE
Server: IAC SB ATCP "MSDP.HEALTH 500" IAC SE
Server: IAC SB ATCP "MSDP.MANA 100" IAC SE

I implemented this for Mudlet, as it doesn't (and won't) support MSDP or open protocols.

I think it's unlikely for two MSDP muds to have the same name, and there's no guarantee that two muds won't use the same ID. One option is sending both PLUGIN_NAME and PLUGIN_VERSION, not a big fan of turning it around (NAME_PLUGIN etc) as it's likely that other PLUGIN_ and SERVER_ variables are introduced some day.

SERVER_ID and PLUGIN_ID sound good to me as well.


Something like SERVER_CODEBASE could be requested for plugins that work with a major MSDP codebase, fairly easy to borrow variable names from MSSP. We might be getting ahead of ourselves though as it's not unlikely that no other mud will implement MSDP.


I'm not getting excited at the thought of trying to standardize MSDP over ATCP. :P

I've seen a few muds with non-unique names (either because it was a common or one-word name, or because they were originally the same mud but split after an administrative dispute). There's also the issue with multiple versions of the same game run by the same person (building ports, test ports, etc).

I agree it's uncommon, but it does happen, and MSSP only includes the name of the mud. I doubt you'd convince any owners to rename their muds, but I can't see them objecting to providing a unique ID. That (along with avoiding the need for two protocols) is why I'd prefer to use a new MSDP variable rather than the MSSP name variable.


That's a good point…


I'd prefer ID to NAME. I'm not opposed to having both NAME and VERSION, but I think it would be easier for me to keep them as one variable.


You've got a couple of dozen muds supporting telnet MSSP, it shouldn't be hard for them to extend it to MSDP. Have you tried talking to any of the mud owners?


I wouldn't suggest even trying - my solution is a dirty hack, plain and simple. But it does at least mean that Mudlet users can utilise my MSDP support.

So SERVER_ID and PLUGIN_ID? I can add SERVER_ID to the general variable list, and I guess PLUGIN_ID should be grouped with the configurable variable set?

Maybe an idea to rename TIME_SERVER to SERVER_TIME, and rename TIME_MUD to WORLD_TIME and place it in the World category.



Would probably be more effective to post a promo of sorts on TMS and TMC as one point of time. One thing I feel is needed is to add a MSDP event handler to my MTH telnet handler, and another way to make it more accessible would be a framework for creating MSDP interfaces for cMUD and MC.

I guess it'd be helpful to link your MC plugin, assuming it's open source?