I figured to create a clone of the MSSP protocol, primarily for server client interaction. A couple of MUDs have created their own home grown telnet specification for this stuff, and MSDP would be supported by tintin++, which with about 2000 downloads a month is starting to once again become a mainstream client, though I'm clueless what the exact market share is.

I put up a quick spec here: http://tintin.sourceforge.net/msdp - and here are the variables under discussion:

General

"ACCOUNT NAME"       Name of the player account.
"CHARACTER NAME"     Name of the player character.
"MUD TIME"           The time on the mud using either military or civilian time.
"SERVER TIME"        The time on the server using either military or civilian time.

Character

"AFFECTS"            Currents affects in array format.
"ALIGNMENT"          Current alignment.
"EXPERIENCE"         Current total experience points.
"EXPERIENCE TNL"     Current total experience points Till Next Level.
"HEALTH"             Current health.
"HEALTH MAX"         Current maximum health.
"LANGUAGE"           Current spoken language.
"LEVEL"              Current level.
"LIFE"               Current health percentage.
"MANA"               Current mana.
"MANA MAX"           Current maximum mana.
"MONEY"              Current amount of money.
"MOVEMENT"           Current maximum movement.
"MOVEMENT MAX"       Current maximum movement.
"SPEED"              Current movement speed.

Combat

"OPPONENT LEVEL"     Level of opponent.
"OPPONENT LIFE"      Current health percentage of opponent.

World

"AREA NAME"          Current location's area name.
"EXITS"              Available exits in array format.
"ROOM NAME"          Current location's room name.

Feedback and suggestions are welcome.

How many people do we expect to use the client <-> server model rather than the crawler <-> server model?

Is this just supposed to make it easier for clients to display data without parsing text for triggers and gauges? Isn't this part of what MXP is supposed to handle?

Hard to tell, but muds implementing MSSP should have a fairly easy time adding MSDP, and visa versa.


Yes, that'd be the main idea. MXP is supposed to handle a lot of things, which is its main weakness. MSDP is just a data protocol, it leaves things entirely up to the client on how to display the data, which allows it to be used by both vt100 and graphical clients, and with the open format muds can easily extend it.

I should have scanned the protocol more carefully (late night out) … I see now that the nature of the variables means that plenty of people will use it.

So now, my next question :smile: Why this instead of ZMP?

It's useless for anything that doesn't match the specific MUD you play. Sure, a custom server can add custom variables, but then each individual client needs code/scripts/triggers/whatever added to know what those variables mean and how to display them. That in turn makes custom variables pretty much pointless for anything outside of custom-written clients tied to specific MUDs.

At the very least you need to "fatten" the data to include contextual information, e.g. grouping the status variables into a STATUS_BAR variable that includes a descriptive name, current value, and maximum, and which can be specified multiple times for multiple status bars Then a MUD can add custom status bars with zero changes needed on any client. e.g. many, many muds have Stamina. Or maybe they want to show the health of a pet/summon. Or maybe they have a round timer instead of movement points. Or maybe they want to show the health of a vehicle. Or spell cooldown/warmup timers. etc. Instead of needing to add variables for it and then updating every client out there to support them, a more generic interface makes things just work.

Because I came up with ZMP. Tintin will thus never, ever, ever support it. But it needs a data protocol, because not having one sucks. Enter MSDP.

MSDP isn't supposed to be a client protocol, but a data protocol that is directly used by the mud client's scripting language. This means that mud client developers only need to add an interface for the scripting language to receive variables and their values - most likely by using some kind of event system. Adding MSDP support to tintin++ will take 20 lines of code using the existing event system - end of story, where as MXP will be a pain in the ass and impossible to support completely, and ZMP is too much overhead and seems to desire to be a client/terminal protocol like MXP and VT100.

Needless to say that tintin will never directly support ZMP, though it will support a ZMP event handler when I get around to it.

Well, for whatever it's worth, I don't see the point to this when we already have a perfectly good data transfer protocol like ZMP. I currently see no reason to support MSDP as-is at the MUD server level.

These don't appear to be right:


The variable set listed can't even be a minimum requirement as it's all Diku.

That's pretty much The Reason to use an extensible protocol here instead of trying to hard-code a list.

Yes, we already knew that.


It's not a requirement, it's just a list of suggested variable names so client scripts can be exchangeable between mud servers - otherwise you end up with HP HEALTH HIT HITPOINTS HITPTS "TOTAL HIT" "MAX HIT" "HIT MAX". It's a pick and choose list of variables so to speak.

Useful variables for the TinyMUD and LP branch as well as generic suggestions would be appreciated.

There's no need to be snarky. (Besides, that was the first time I said that. You might have had some good reason for making your own protocol, which is why I asked the question of why this instead of ZMP.) You came here asking for feedback; my feedback is that you're trying to solve a problem that's already been solved, and in a superior fashion at that.

Now all we need is someone to suggest implementing it in XML and this thread will be complete. Anyways, I'll likely come up with a zmp version of the spec so there's no need for fanboyism at this stage. Feel free to make a positive contribution instead and give some feedback or suggestions on the variable list, unless you particularly enjoy exchanging snarky replies with me.

Why do you have to turn everything into personal insults?


If a positive contribution must be of the form "this is great, let's do this", then I'm afraid that I cannot make any. If that's all you're interested in I'll go away. I thought it was a positive contribution to suggest that we use technology we already have that is very good (and better) at solving exactly this problem.

I already said I'll add a zmp version, so yes, help flesh out the variables and stop beating the dead whore?

What does it mean to "add a ZMP version"? Isn't the transport mechanism kind of the key point of a protocol? At this point, we're not talking about a protocol anymore, but rather an ontology.

I think it's hard or basically impossible to fully capture the set of variables all MUDs use, so it's more interesting to work at a higher level. Elanthis suggested this already: instead of trying to describe all possible stats with current/maximum values, it's much better to solve the abstract problem and have a generic status message.
So, in this light, I think that any attempt to list out all variables for all MUDs is basically futile. Besides, custom MUDs will have all kinds of stuff that we have no way of foreseeing.

Is it any wonder why nobody wants to devote time to supporting these things when there's so much bickering and arguing about who's variables do what when transported in a certain way?

Welcome to the world of standards design. The nature of the beast is to talk about very nitty-gritty details. That said, we've certainly had our own interesting takes on bickering here.

MUDs can add a vt100 bar if they want that, both zmud and tintin support it, though admittedly it's not easy to implement.

A bar variable could be added for MUDs that want to go that route, the following is compatible with vt100 interface implementations:

"PROMPT BAR"     "vertical location", "string"   The mud is expected to use NAWS to determine
                 the right width for the given string. A positive vertical location value
                 places the bar the given number of rows above the input bar, a negative
                 value places the bar the given number of rows down from the top of the
                 screen. A value of zero leaves placement up to the client.

The actual MSDP implementation shouldn't be hard coded but be implemented using the client's scripting language, which would avoid the whole MXP drama.