Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ General ➜ MXP Spec clarification
MXP Spec clarification

Posting of new messages is disabled at present.

Refresh page

Pages: 1  2 3  

Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #15 on Sat 08 Sep 2007 11:59 PM (UTC)
Message
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.
It is much easier to fight for one's ideals than to live up to them.
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #16 on Sun 09 Sep 2007 01:44 AM (UTC)
Message
Quote:

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.


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:

Quote:

Zugg: (22 Jan 2004 21:20 )

No, actually, this is just what we intended. By having MXP always on for *all* MUDs, it gives zMUD users the ability to use HTML in their messages on ANY MUD even if the MUD doesn't have MXP support.


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).
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #17 on Sun 09 Sep 2007 01:49 AM (UTC)
Message
Quote:

I doubt Zugg will mind if someone steps up and fixes the issues with MXP that are being addressed in this thread.


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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #18 on Sun 09 Sep 2007 02:06 AM (UTC)
Message
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.
Top
Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #19 on Sun 09 Sep 2007 02:24 AM (UTC)
Message
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.
It is much easier to fight for one's ideals than to live up to them.
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #20 on Sun 09 Sep 2007 09:24 PM (UTC)
Message
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:


 <addtoinventory>blue sword</addtoinventory>.


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:


Received new item: blue sword


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

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #21 on Sun 09 Sep 2007 10:02 PM (UTC)
Message
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.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #22 on Tue 11 Sep 2007 03:20 AM (UTC)
Message
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.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #23 on Tue 11 Sep 2007 05:55 AM (UTC)
Message
Quote:
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.


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:
Quote:
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.

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.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #24 on Wed 12 Sep 2007 03:18 AM (UTC)

Amended on Wed 12 Sep 2007 03:19 AM (UTC) by Shadowfyr

Message
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?
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #25 on Wed 12 Sep 2007 06:10 AM (UTC)
Message
Quote:
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.

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.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #26 on Thu 13 Sep 2007 01:26 AM (UTC)
Message
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.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #27 on Thu 13 Sep 2007 03:52 AM (UTC)
Message
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.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #28 on Fri 14 Sep 2007 03:32 AM (UTC)
Message
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.
Top
Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #29 on Fri 14 Sep 2007 05:25 AM (UTC)

Amended on Fri 14 Sep 2007 05:27 AM (UTC) by Shaun Biggs

Message
Quote:
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?

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.

Quote:
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?"

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:

Num  Level  Price    Qty  Item
---  -----  -------  ---  -----------------------------------
  1      1       20  ---  an Aylorian Dirk
  2      1       20  ---  an Aylorian Sword
  3      1       20  ---  an Aylorian Axe
  4     10       10    1  a scimitar
A text and a graphical version could both be shown by the following:

<shop>
<item level=1 num=inf price=20>an Aylorian Dirk</item>
<item level=1 num=inf price=20>an Aylorian Sword</item>
<item level=1 num=inf price=20>an Aylorian Axe</item>
<item level=10 num=1 price=10>a scimitar</item>
</shop>

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.
It is much easier to fight for one's ideals than to live up to them.
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

90,167 views.

This is page 2, subject is 3 pages long:  [Previous page]  1  2 3  [Next page]

Posting of new messages is disabled at present.

Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home