MXP Spec clarification

I decided it was about time to get clearification on this issue from the horses mouth, so asked Zugg about the whole < and > issue, this was my letter and his response:

I refer to the MXP spec by Zugg at:


http://www.zuggsoft.com/zmud/mxp.htm

"Since a normal < symbol is interpreted as the start of an element tag, you must use &lt; to refer to a less-than symbol directly."


That says "must use" not "can optionally use if the mode is open". I coded from that spec.




There is simply no reference to this in the spec, and in any case it doesn't make sense. First, what the spec says about "open" mode:


"In particular, if the tag element is Open, the user can change the color, gag, or redirect the tagged line. This is useful for various chat channels on the MUD.
...
When the mode is changed from OPEN mode to any other mode, any unclosed OPEN tags (tags that were used while in open mode) are automatically closed."


First, the purpose of open mode is simply to allow the user to insert things like <b> into chat text. The spec makes this clear.

Second, the spec makes clear that tags in open mode are automatically closed, if necessary.

For example, a player might chat:


<b>Hi there


According to the spec, this is allowed, the player can chat in bold, and he doesn't have to close the tag. The client will close it for him, otherwise every other line would be in bold also.

Now, Zugg says that if the client does not see </b> it "assumes that the original tag was normal MUD text". This completely and utterly contradicts the spec.

---

Let's go back 5 years to when I was adding MXP to MUSHclient. I sent a series of emails to Zugg to clarify parts of the spec. His answer to this one makes very clear that you don't "look ahead" to see if you get </b> before processing <b>.


Date: 11 Jan 2001 10:00:02 AM
From: zugg@zuggsoft.com
Subject: RE: MXP protocol - 2


Nick:

When do you start parsing for MXP tags? Once a newline has arrived? I ask because of the question we had yesterday about when triggers are evaluated. It is the same basic problem. If you parse when the TCP packet ends you may be half-way through a tag.


Zugg:

*** No, you parse MXP just like you parse ANSI color. You parse it right away. So, as soon as you see <B> you switch to bold font without waiting for the </B>. Then, at the newline, you close any OPEN tags that are still active. And yes, your TCP packet might end in the middle of a tag, just like it might end in the middle of an ANSI color sequence, so you have to plan for that and handle it.


The answer above makes it clear that <B> is converted to bold, regardless of what follows. I stand by the behaviour of MUSHclient 100%.

The email I posted is "from" Zugg. Yes, <b> would be considered a tag, <yadda, yadda!> is treated as text, according to him. Your correspondence only refers to a "valid" tag, not one that isn't recognized, so it hardly applicable to what happens when its not recognized. I sent another message to him in reply pointing out that the spec doesn't in fact make this clear and needs to be fixed. His email said basically, "I think it already says this", which it doesn't.

Point being, you are following the specification, but the specification is incomplete with respect to the correct behaviour. That is what I wanted to find out, since the issue keeps cropping up.

I understand that.



True. However if < is not being converted then I am taking the fairly likely case that something like this will occur:


Obvious exits: <I>nn <B>lacksmith <U>ndertaker


Now if < is not being converted then we have the issue of how this line will look. It will be rendered by the client (perfectly validly) as:


Obvious exits: nn lacksmith ndertaker


Sure, we can catch things like <O> and render them as <O>, however you have shifted the problem to "all exits look strange" to "some exits look strange" which I don't think is a big improvement, do you?

You, or I, could write a small plugin. It would do OnPluginPacketReceived and scan the line for <x>, then if "x" isn't a valid MXP tag replace it by &lt;x&gt; (if MXP is active). As I said, that would fix *some* tags.

The spec says "you must use &lt; to refer to a less-than symbol directly" (my emphasis). No wriggle-room there. You *must* do it. If the server does not do it, it is not following the spec and is wrong.

The client cannot detect the different between:


Exits: <I>nn

You say <I>hi there


How can it? The fix is not a client-side fix. Sorry.

OK, look at this correspondence in 2001 between Zugg and me:

---

My email to Zugg


-----Original Message-----
From: Nick Gammon
Sent: Sunday, June 03, 2001 9:04 PM
To: Zugg
Subject: Two important changes :)


Hi Zugg,

Two important changes to zMUD which I think are essential to make it and MUSHclient reasonably similar in their handling of MXP, even if you don't change anything else ... :)

1. Make it ignore any unrecognised tags rather than display them. This gives us both the chance to cope with new tags in the future without having to release our updated clients on the same day and try to get every player to install it, both of which are probably impossible tasks.

eg. tag <blah> if <blah> is not recogised, silently discard it (and, of course </blah> )

...


---

Zugg's reply


From: zugg@zuggsoft.com
Sent: 4 Jun 2001 01:16:40 PM
To: Nick Gammon
Subject: RE: Two important changes :)


Hi Nick,

Yes, I agree with (1). This is what made HTML powerful and extensible.

However, in the example:

<BLAH>Test</BLAH>

The "Test" text should still be displayed I think. That is what HTML does.

...


---

You can't get much clearer than that. Zugg agrees that clients should ignore non-recognised tags, which is what MUSHclient does.

MUSHclient does exactly what Zugg says it should do, display "Test" but not <BLAH> or </BLAH>.

Now, time to stop arguing over the spec and get the server developers to fix their bugs.

Double post? Click the Refresh Page icon to redisplay the page. Refreshing might resend your last message.

Sigh.. Your going to hate this Nick, but the most recent response from Zugg follows:

I have taken the discussion to his forum. :)

Effectively the response is that, for zMUD, MXP is always on. Full stop.

Thus, from zMUD's point of view, it must always attempt to display tags (like <O>ut) because it is always parsing MXP, and the MUD may simply not be MXP-enabled.

Personally I think it is a little strange to try to parse MXP from a non-MXP MUD, but there you are.

What zMUD does, is start up, with MXP enabled, and in "open" mode. Thus it is allowing the normal formatting tags (like <B> for bold).

I have asked how it handles:


Exits: <B>lacksmith


I haven't got a response yet, but to me this is the key question.

I am expecting the response "don't process it unless you get </B>", however this violates the spec which says that tags are automatically closed, and thus the </B> is not required.

There *is* a middle ground, to make a MUD that complies with MUSHclient (and the spec) and zMUD, and that is to do what the spec says. That is, to always use &lt; for <, like the spec says to do. However I don't see - still - how this will work with non-MXP MUDs.

Yes. That is I think the main issue. With zMud you can't turn it off (as far as I know). Personally I think he simply overlooked the details for how to handle the situation when writing the specification. But I am guessing that his intent was what he said in his recent emails, since he assumed it would be on at all times. This makes sense, since in general you don't make clients that arbitrarilly turn off a certain protocol, instead of determining what to do based on negotiations. Though usually you don't have them always on either. As you point out, there are cases where it doesn't work, but for 90% of cases it does.

For personal reasons, I like being able to use the Open tags as a player, even on muds that don't support MXP, but on the other hand, it might be better if MXP had to be manually enabled or negotiated to work in both cases, just for the purposes of general sanity, in spite of the fact that having it that way would annoy the hell out of me. ;) Though, if both clients worked the same, this would hardly matter, since Open codes wouldn't work for anyone on a normal mud anyway.

At least one person tried briefly to develop something called ZMP (Like we need another one, with MXP, MSP, MCP, etc.), which was supposed to fix this by using escape codes for everything and thus *fix* what he considered problems. In reality, the codes he suggested just caused implimentation problems (I hate to see what it would have done to unicode) and replaced <> tags with unreadable, but functionally identical, escape sequences. As far as I know, development on it died out.

---

BTW. Which thread on there? I don't see anything that looks like it on the forum anyplace.

He has a developer section, I think you need to apply for it. I imagine he would approve your application as you have been having discussions with him about it.

As I posted on his forum, I simply don't see how you can have MXP always on. Here is an example conversation:


Player 1: How you you make bold text in an HTML page?
Player 2: You put <b> and </b> around the words in bold


Now if MXP is on, without the knowledge of the server, and without the client turning it on (or indeed, in zMUD's case being able to turn it off), then this conversation will be converted to (in part) bold text.

I don't see how you can have MXP on without some form of negotiation. It is not the same as normal output. You will always have borderline cases like people talking about <B> which will appear normal MXP.

Yeah. I get the sense that he figured, "This is so rare a possibility, it hardly matters." And he is mostly right. I can think of only one case where it would be common, and that is it you telneted into a game like Tradewars 2000, which your client wouldn't work for anyway, since it uses *lots* of text positioning. His though, would be able to play it, except that all the command display menus are like:

<I> Ship Information
<N> Navigation
...

Ooops!

But except for a few diehards that played it in the BBS days, hardly anyone plays it anymore and muds generally don't do this. Its far more common for muds to have entire words or phrases, like <North>, or <The Plaza Fountain>. You example of <N>orth is unlikely, simply because all muds use similar code bases and usually N, S, E, W, etc. are aliases to the commands north, south, etc. It makes no sense for them to display the alias that way, as though it is the actual command. The number of times someone it likely to be discussing HTML on a channel or in tells is very small too. Yes, its a problem, but imho it is probably an extremely rare one, which is why Zugg, as far as I know, never had huge numbers of people complaining about the behaviour.

Frankly, I think the guy with ZMP had one thing right. His didn't cause these problems, but since the intent was to allow people with compatible clients to use things like color, even on non-MXP muds when talking to each other, ZMP also wouldn't work the way MXP was intended to. Its a catch-22. If its on only when asked for, you can't use it as intended for general players, but if on always, some unusual and rare situations will screw you up.

Personally I don't like design where "it works most of the time", still there you are.

It is obvious that zMUD is not going to be changed, it is fundamental to the way it works. For example, in zMUD you can do something like "you see <b>trouble</b> ahead" in "send to output" in their triggers. In other words, parsing MXP is pervasive in the client.

In MUSHclient you would use ColourTell to achieve a similar result.

I have asked that - at the very least - he append a clarifying note (which I have written) to the MXP spec, to make it clear to server developers that the two clients behave in different ways, and to suggest coding in such a way that is compatible with both clients.

All of this reminds me of IE vs Everyone Else when it comes to web standards and the resulting web developer hacks to deal with the discrepencies between IE and the standards. The thought of having to do client sniffing in a similar fashion to how browser sniffing is done is just silly. Follow the spec, and let the chips fall where they will.

What can you do? I have commented at length on the zMUD forum about how the behaviour of zMUD does not comply with the spec.

Zugg said there today:



In other words, the spec is wrong, and he hasn't had time to fix it. However the spec is all we have to go on, as the code to zMUD itself is not available.

Sorry to resurrect this thread, but a recent discussion about MXP on MudBytes brought this thread to my attention.

Within this thread, I've noticed it mentioned that zMUD has MXP always on. Having been using zMUD for close to, if not more than, 10 years, I can state that this is not so. As far as I can remember, there has always been an option to disable MXP parsing within the settings. I'm not certain if it has always been the case, but I am certain that as of the first post on this thread, dated the 16th of January 2006, that the option did exist to disable MXP within zMUD. That option has been there since at least version 5.55 which was released some time in the late '90s.

I've never played any MXP enhanced muds so I always had this option disabled. I did, however, notice that if it was enabled, that it sometimes caused my prompt to disappear because it did start with the less-than character "<".

However, with more recent versions, this no longer happens with MXP parsing turned on.

As for the MXP specs not being complete... There are some very talented programmers on this and other related forums, I doubt Zugg will mind if someone steps up and fixes the issues with MXP that are being addressed in this thread. Unless the issue isn't with the specs itself, but rather how the clients parse them.

Yes, the people above are mis-informed about turning off MXP in zMUD. The actual issue is that zMUD has MXP enabled by default. Most people don't bother to turn it off, since it rarely ever comes up, if at all, so things like answering questions about HTML can be tricky. The mud I play on has somewhat banned the use of tags on public channels specifically because of how it affects most zMUD users.

See: http://forums.zuggsoft.com/forums/viewtopic.php?p=89248

(This may be a closed forum if you aren't registerd as a zMUD developer). Anyway, in it Zugg himself says:



He makes it clear there that MXP is always on for all MUDs.

Maybe it has changed since then, but the design intention seems to be to have it on all the time (with all the problems that causes with strange tags, I may say).

What are we supposed to fix exactly? The spec? zMUD? Both are out of control of anyone except Zugg.

MUSHclient follows the spec as far as it could, and in areas where zMUD does not follow the spec, Zugg says "the spec is out of date". Does that mean I should change MUSHclient to *not* follow the spec, so both clients are not following it, but at least are doing similar things to each other?

There are other places, where arguably the spec is silent (in particular the handling of incomplete tags), so you can't really say that either client is following, or not following, the spec.

Realistically, we need, on all sides, to take a clear stance on what the behaviors *should* be and why, then fix the spec first, then the clients second. Both are probably not working as needed to follow any reasonable specification. After all, if the spec is silent on some issues, then obviously its unlikely that any client can be said to be operating as intended in those case, and where the spec if not doing what the original client does, consideration needs to be taken as to **if** it even makes sense for the client to have worked that way in the first place.

In the one example, if you have something like, "<I>nn of Valor", it makes no sense to *allow* that to be sent without escaping, not does it make sense to even allow chat channels to support tags, instead of auto-escaping them, and if you do allow it, then you need to be clear on the mud that they won't appear as normal text, *unless* they escape them. (Alternatively, a special symbol could be used to instead indicate that it *shouldn't* be escaped). But, we need a clear spec, not one which people can misinterpret, and not one that breaks in certain cases, like the example I gave above, when you think you are doing it right.

The problem with continually sending escape codes occurs when people are trying to demonstrate something about HTML, and you add in escape codes to note screw up people with MXP, and the people without MXP wind up seeing the escape codes in there.

In retrospect, the best thing that could have been done to begin with is to have had MXP initiated with an escape code. That way clients that do not support MXP would just throw out the escape code and show the tags as normal text, while the MXP enabled clients would parse the tags as they currently do. That, or have a tag set very different from HTML.

My personal view is that MXP is never going to work fantastically well for the following reasons:

• Despite having a telnet protocol for detecting whether or not the client supports MXP, zMUD has it turned on all the time.
  
• Because of this, server writers assume they can get away with mixing MXP and non-MXP like;
  
  

  
  This is the <I>nn where you can get a <b>hot</b> drink & a pie.
  

  
  
  zMUD parses this sort of stuff OK because it simply displays stuff that is not valid MXP tags as straight text.
  
• The spec is silent about how to handle erroneous tag situations, leaving different authors to handle them in different ways.
  
• zMUD is not being developed any more (instead, CMUD is), thus any problems in the way it implements the spec are unlikely to be fixed.
  
• Any problems in the way zMUD implements the spec that Zugg himself wrote are dismissed as "the spec is wrong" and "I will fix the spec one day".
  
• MXP is really being used as a style markup language (note the emphasis on specifying bold, underline, colour changes etc.) whereas what would be a great deal more useful would be to specify content markup.
  
  I know you can make your own tags like <inventory> ... </inventory> but the stuff between the tags is still displayed.
  
• The idea of having "open" tags was apparently designed to allow people to self-colour their own chats (etc.) however this is open to abuse. Things like:
  
  

  
  Nick says, You are an <COLOR FORE=red><FONT FACE=Courier SIZE=40> IDIOT! </font></color>
  

  
  
  Who wants to be insulted in a 40-point font chosen by their adversary?
  
  It also doesn't work in other environments, where the player may have chosen a different color scheme for their local use. For example, in the above case, if they had chosen a red background, the red word disappears against it.
  

I would rather have some sort of protocol where things like inventory are updated as changes are made (eg. if you add an item to your inventory, a small tag arrives saying something like:



With this sort of thing, the client can update its internal inventory list, maybe play a "ping" to show you have got a new item, and maybe display a small message in a text box:



Similar things could be done with battle messages, changing rooms, learning skills, and so on.

For what it's worth, I fully agree that the way to go is to have a protocol that lets the server describe what is happening such that the client can do what it wants with that information.

I still think markup is useful, but what may be needed is something closer to the style sheets that they eventually added to HTML. Mind you, there are some issues with those, not the least being that they where tacked on as an after thought, to extend functions like <span>, etc. and no two browsers **currently** support both names for "all" of those elements, or a clear and easy way to attach the styles to any of those things.

Now.. One issue I can see is GUI vs. text. It may be necessary, as part of any such protocol, to define two styles for every such item. For example, <style_gui>name="inventory" blah...</style_GUI> and <style_text>name="inventory" blah...</style_text>. That way, if a client doesn't support the GUI elements at all, then trigger based systems could "still" parse the style and generate changes to the inventory list, in the text only display. Someone could instead make a client that has no support of text mode inventories, etc. and instead only supports the GUI version. The client would still handle insertion/deletion of items to both the same way, but it only accepts/responds to changes in the style data for the method(s) it handles. Such a style sheet system could mean that, for things like inventories, you could change the color or the item in a "hands" slot to designate that it was damaged, for example. Mind you, the question them becomes "how" the color should change. Is it an overlay, the background or the outline? Do those need to be named to, or do you provide, as part of the basic GUI, some way to designate which one to do. Or, do you, as I have suggested, only fire an event for a plugin, which will handle how to display the inventory, and thus what to do if you change a color element.

The later is less flexible than having the server define "all" elements, but would require less bandwidth to "define" the interface, since you could instead just provide an interface plugin, which had all the handling in it. And, we need to consider allowing someone to "override" what the server wants, by intercepting style sheets, markup and commands to add/delete/sort, etc. anything in them. This would allow the design to remain flexible from the user standpoint, instead of locking them into the interface of the server, if they opt to do something entirely different, kind of like how EQ2 can have UI patches added, to alter the look and feel of its GUI, even though the data remains the same. And that is done by altering the markup, etc. in the XML files used to define how it should look. Though, theirs doesn't let you alter behavior, just display.

I don't understand the problem. Send the client the data with descriptive markups describing (as it were) what the data is, and let the client decide all its own whether to format it using a GUI or text or whatever.

It also solves this problem:

The whole point of style sheets, incidentally, was for the HTML to describe the data, and leave the formatting up to somebody else. That is to say, the HTML would define the structure of the data, and the CSS is applied to that data to generate a webpage. Kind of like XML and XSLT. (Except that, naturally, that's not how CSS is actually used in practice a lot of the time.)

Anyhow, if you leave such formatting up to the client, which is where it belongs in the first place, then there is no longer any need to be intercepting and overriding stuff in over-complicated ways.

The reason you may want to have a "GUI" and a "text" system is that there are things a GUI can do that ***is not possible*** in a text system. For example, you may want to have a window that shows a shop include a "buy", "sell", etc. button, or even tabs, like in EQ2, where if you go to a mender you get three tabs - Repair, Buy and Sell. Each also has a button/button(s), like "buy 1", "buy amount" and maybe "restock", as in if items stack in 100s, but you only have 48, you can "restock" the other 52, instead of entering a number or buying them one at a time. Same with sales. You have "sell" and "sell stack", and now, for items you have previously sold, you can also "buy back" for the same original value (the last 10 items or something).

Point being.. If you try to force the "text" version and GUI both conform to *one* set of definitions for what is "allowed", you invariably handicap the GUI. The only way I could see around that would be to not allow such functions to be used at all *unless* it supported either "links" or "GUI". And, that still presents a problem. How do you put links for such buttons into the text version, without it looking lame. Obviously, it not as simple as just dropping them into the same place as the GUI would have them. It a) wouldn't look right in most cases, and b) it might work better if formatted in a completely different way. Graphics and text markup are simply **not** interchangeable in that respect, without *creating* compromises that limit what the client can do, and what the developer can expect it to look like. I just don't think you can make one single markup design work in "both" modes, which means you kind of, by default, need on for the GUI that looks good, and one that looks good in the text mode. There are bound to be cases where the two designs have no analogous translation, so why force the system to try to make them analogous in the first place?

That's not the point if the underlying data is the same. Obviously the GUI interface can manipulate data in ways not really feasible for text (drag and drop, for instance) but the data is the same. So I don't understand why you need to split in two the data being sent if you're already in the context of a descriptive protocol.

I think that you are confusing the description of the data with the server saying what it should look like. So, if the server is sending the data, then the client has everything in hand, and everything else is how to display that data. When you say that the GUI is necessarily handicapped, you are assuming that somehow there is data that is not being sent, and that is what makes no sense to me. As a server your role is not to decide how the client is going to format the semantically rich data you are sending: your role is to send the data in some descriptive, parseable form, and let the client figure out what to do with it.

Umm. No, I think you are the one confusing the data with the description, to some extent. Ok, true, if you allow for something like, "Add this item to the inventory", to somehow effect the text system, then sure. Realistically, unless that is being displayed in a separate window, you don't even want the text system to handle adding/removing items from such a thing. It does make sense for a GUI though. But, yeah, I see you point, for most data. There are however situations where it might not make much sense to send the same data. If you know the client doesn't support GUI, you can do any of the following:

1. Only send the text data in your data block.
2. Send a special text block, which can't contain graphical info.
3. Send the image name/location for the item, color information, text, and what ever else is needed for it, then have the client throw out the stuff it doesn't need.

The first option could be part of the spec, based on negotiation. You do not want the third option though, since that would waste bandwidth you don't need to, in order to send information the client can't use anyway. You may be correct however in assuming that option #1, based on what is negotiated, is the best choice. I was looking more at the larger view of what data "would be" needed in both cases, rather than if the same transport method could be used in all cases.

I think there's really a fundamental disconnect here. I am talking about a protocol that sends computer-parseable data that the client is free to interpret however they want. The point is not at all whether or not a text client would do anything interesting with the message "item 1234 added to inventory". The point is that the server is informing the client of the events that happen around the character, and the client is free to do whatever it wants to display that data. In a sense, the whole 'text vs. GUI' discussion is irrelevant, since the data being sent is the complete data set.

In other words, the 'text client' is not going to literally display the data sent by the server. The client will instead read the data, interpret the events in some meaningful way, and decide to print out the message in some text form.

Part of the point is that you would never be sending color information, because that is a decision for the client in the first place, not the server. The server shouldn't be deciding what color the client wants to see the game in. Maybe the client wants room names to be in yellow, not green... etc.

Wrong. Sorry, but I don't agree with you at all, some people may very clearly **want** for aesthetic reasons, or due to actual need, to send color information. How else do you send that sort of thing? Send a name, then *hope* that, despite the clear requirement for some puzzle, etc., that the word/image/button is colored blue, that the client isn't replacing that with orange? Either you are talking about something entirely different than I am, or you are hugely missing the point of being able to send colors and/or GUI design data.

You **are** missing the point when I talk about bandwidth. If any part of the data being sent is like.. GUI data, which can only be used by the GUI, but someone is intentionally using the client in text only mode (or a client that only supports it), then throwing 500k across a connection, when the client can only use like 1k of it, is just stupid. You have to be able to have the server ask at some point, "Can you even use any of this information, or should I instead send you the short version?" It just doesn't make any sense to send stuff the client can't use, especially if the reason for that is because its designed to run on systems with very little bandwidth.

And some people may very clearly **want** for aesthetic reasons, or due to actual need, to change the colours that come from the server to whatever they choose. Either to make things stand out, making it blend in better with a pattern of text, or to remove it completely. Putting things completely in control by the server takes out a lot of options for the users. Even with a pure text client, people can do amazing things with text libraries such as ncurses.


I certainly hope that this is severe exaggeration here. If you can only use 0.2% of the information in text mode, then go play WoW or something. Nearly anything that could be used by the client to make a gui can just as easily be displayed as text. Inventories of shops, contents of containers, items worn, channel displays, exits, etc. Most of the tags should just be describing the data being sent, not sending graphics or whatnot. Not even graphical games do that, they just send the client information on what can and cannot be seen, and let the client figure out how to display it.

Take this shop listing as an example:A text and a graphical version could both be shown by the following:
Let the client sort out how to deal with it, and you don't have to worry about if the client is text based or graphics based. Graphics could be loaded up by item type field or item name to display things in inventory.

Sigh. I am thinking in broad terms of what someone "may" do in the future. Sure, you are correct in that, in general, if all you are doing is sending a list in some format that will show it one way in the GUI and one way in the text system, its not a big deal. All I am saying is, you might want to have a means to negotiate clearer about what is and isn't allowed, so that, to use your inventory example, you don't get something as bad as:


Which is nearly doubling the data involved, when half the stuff in the list is "not" essential at all to display in text. Mind you, no mud is *currently* likely to do that. But something coming from EQ2 might ask, "Well, why if you have a GUI can't you at least show some pictures of what the thing is, and provide something sort of like the "dressing room", where you can look at it in 3D? Hell, I would love to see that myself, even if I had **never** played EQ2. To me, it adds something to at least get a sense of how big a "huge sword" really is, just how spiky the spikes on the mace are, etc. Sure, I can imagine it, but which is seriously more stunning, the battle scene with Sauron in the movie, or the convoluted prose of Tolkien? Some people may want to former, even if the rest of the game is text. And, if you start adding that sort of data into the stream, you may want to make sure there is "at least" some concept in the protocol which allows a client to negotiate "down" to a level that won't be sending all of it, instead of relying on the server coder to implement some addon hack, which only works with their server, and which ever client they cobbled together to do it.

And sure, they could set it up to simply let the person enable/disable some content on the server end, for that character, but that only works where someone bothers to do it, in which case, you are right back to getting 2-3 times the data, and throwing 1/2-2/3 (or more) of it out, instead of just requesting, "Don't send me what I can't use.", in the first place. Have thing that would require a GUI capacity, or a plugin for graphical elements, place those items in a category of "graphical features", which you can negotiate out of.

At the very least, make sure that there is a clear concept of how those additional elements "must" be included in any protocol, and negotiated, so if someone does come along with something of the sort, you can extend to protocol in a way that the client can deal with effectively, not just figuratively scratch its head at and throw out. If it can't use it, then have the protocol establish it, and the protocol on the server end figure out what to send and what to not bother with, not the client, which is a bit like closing the barn door after the herd has already stampeded over you lawn.

See what I am saying?

We don't need to implement the features to do any of the stuff I put in my example, but we should have the "server" end firmly in the position of being responsible for determining if it should cram all those things into it in the first place, or if, perhaps, the guy with GenericClient++ shouldn't have all the extra stuff thrown at him to start with. Color markup, etc. would be handled in a style sheet system instead, so you could "override" the styles for inventory, or shops, etc., to make it fit your aesthetic, or you could use what the "mud" wants you to see instead. That is fine. Some data though, is not needed, wanted, or useful, to a text client, so it makes no sense to send it anyway, instead of negotiating with the server using something like, "Can do 3D, can't do 3D, can do images, can't do images, can do tables, will do tables, etc." That gets you *your* example, and tells the server, don't send me the other stuff.

I completely see what you are saying. This is why I can say with absolute certainty that you are flat out missing the point of making protocols concise.

What you turned my example into has many completely superfluous bits of data in it, and can still be used by text clients which are creative about things. All you would need is some type of basic flagging for any of the items you mentioned.



If you have to download the images for 2D and 3D objects, might as well have a whole object pack that will match the images and basic affects on the items, vaguely like having CSS for web pages. It can notify the client on how to colour the text, what font it should be displayed as, what images to use, etc. Adding extra options for changed flags should be no problem at all, and should be easily modifiable by whoever is running the server. Possibly even easily modifiable by people who just want to make their own alternate graphics packs. Text based clients can use the options at least to display what extra flags are on said item, if it is wanted. That being done, the only wasted bit of code would be the object id... a far cry from the immense amount of waste that you have claimed would occur. Actually, with this example, noting the level and price may wind up being redundant for certain items if they are at the defauts, cutting back even more on the amount of data wasted, possibly even saving some bandwidth occasionally.

Also, supporting the tags should be somehow requested by the client if the mu* intends on being able to be used by even plain old telnet. Anything after that can be dealt with on a case by case basis. If a client choses not to support certain tags, then it can ignore them without having the server waste processing time trying to figure out if each individual player can deal with the tag. The server should not be burdened with trying to figure out what the client can do.

This thread has moved far, far off of any clarification of MXP though, so I'm going to drop the matter after this post.

Yeah, it shifted to "Maybe we should replace it, rather than try to fix it?", some time ago. I will still say you are not getting the issue. I talked a while back about a system for 3D that would do limited scenes, which could be changed dynamically as needed. Got sort of the same argument there, "Well, if all you want is sun position, then just code that into the stuff you download for the plugin/client, then just send the position." It missed the point that this was an "example" of what someone might do. It doesn't matter if I hard code something that is supposed to help make it look like its snowing, if the next week everyone on the mud agrees we need to have a volcano go off, and now we need "ash". Similar code? Sure. Same code? No, so it "must" update more dynamically. Same with just bugfixes. Wrong texture, etc.? Patch the text sent. But you still "send" the text.

Point being. The example given in my last post is the "minimum" I might imagine someone doing, and it ignores one key feature I think most 3D systems currently lack: The ability to update the content with the same ease as you update the "code" for a room on a mud. You are assuming static information, which one simple name, linked to a pre-downloaded definition file will handle. Ok, in that case you are 100% correct, its not a huge issue. But that **may not** be what is actually being sent.

Mind you, it may be possible, with some allowances for background tasks and such, to find ways around that still. Like updating the object via a different port. Or even, as I considered, using a torrent like system, which could slowly patch your files in the background, and where the tracker could "inform" the client that file X in directory Y has been patched, as needed, and update critical files without having to force the client to download the whole file at once. Decent bandwidth limiting could even reduce lag for dialup to a point where the game was still playable, while patching, though it would lag some still. It might not be a huge issue if the torrent system was "aware" of user commands and actions and could delay its own actions for "idle" periods, like when the player goes AFK, etc. You can't do that with an external patcher or torrent client.

The benefit is obvious to the server owner. No huge bandwidth hit to them every time someone is downloading their plugins/files.

But yeah, this has strayed from the original post, but then, I don't think we are likely to draw any more conclusions from the original than we already did: 1. Its broken. 2. It probably won't be fixed by Zugg and 3. We are unlikely to see it fixed any time soon.