Element definitions cannot define other elements

The MUD I play (Discworld MUD) has a small collection of Odd things they do with MXP which seem to be not quite working with MUSHClient.

For example:

is designed such that:

should produce a little right-click popup menu on the link on the NPC.

However! This doesn't work in MUSHClient, while it does in CMUD. (No criticism implied. I only downloaded CMUD *shudder* to test this specific error.) Turning on MXP debugging, I get

for all of the definitions similar to this.

I'm not really sure what this means, and I'm not sure if it could be a bug or not, since it produces the same message if you replace !EN with !EL. Anyone have any more info about what this error code/message is about? I can't find anything related in the MXP spec or the element and entity posts linked to from the MXP section header.

Take a look at:

http://www.gammon.com.au/mushclient/mxp.htm#userdefinedelements

In my design notes there I suggest that element definitions are for defining "atomic" elements (that is, elements that simply do something), not elements that define elements.

In my notes there I specifically disallow elements defined within elements, that is:


The elements in the definition list should be simple atomic elements, not closing elements or definition elements.

• <!ELEMENT bold '<B>'> is OK
• <!ELEMENT notbold "</B>"> is not OK
• <!ELEMENT defineit "<!ELEMENT italic '<I>'>"> is not OK

I think this makes the code too complex, if you can have an element that defines something that defines an element, why not nest it further?

Also see:

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=226

There I say that (in MUSHclient) elements can only define inbuilt elements, that is you cannot define user-defined elements with elements. Again this is for simplicity of implementation.

Anyway, aren't they going about it in too complex a way? See this:

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=238

(Scroll down to the "send" tag).

You can make an element bring up a pop-up menu, you don't need to nest definitions to do that.

If I may suggest to MUD developers, as there are two main clients (three if you count zMUD and cMUD as different) that support MXP right now, you test on both clients. We all know that they both implement MXP a bit differently, there have been lengthy, lengthy, discussions about the differences.

For me to change MXP to nest definitions would be a heap of work - work I don't propose to do. So I suggest that unless Discworld wants to say "only runs under zMUD/cMUD" - that they rework their code.

I'm fairly sure that Discworld's MXP support was targetted at WhelkMud (http://whelkmud.sourceforge.net/ written by Discworld's original implementor). So if it works in CMUD, it's purely coincidence.

I have a half-complete plugin written in Python to convert Discworld-MXP into MUSHclient-MXP but it's going very slowly :(

Looking at WhelkMud's page, it looks like he goes beyond simply targeting Discworld's MXP for WhelkMud as a testing platform; it looks like he even added things to the standard that (presumably) only WhelkMud would support. In that case it would be easier if they simply didn't call it MXP -- at the least, call it a fork of MXP or something like that.

Hmmm - looking at the WhelkMud page (and sympathetic as I am to Whelks after playing Myst) I can't help thinking that this is adding extra complexity to a system that already has some problems, namely the fairly minor differences between zMUD and MUSHclient MXP implementations.

One of the MXP "extensions" he mentions is paging. I quote:



This sounds fantastic in theory, but in practice I cannot think of a way of making a GUI application "page" its output. I tried for a while and failed, with MUSHclient.

Paging is really a throwback to the old telnet days, when data simply scrolled down the screen, and it was helpful to "page" it by stopping when a page-full arrived, so you could read it,

However with modern GUI clients, if you miss something you simply "page up" and the scroll bar moves, and you read what you missed.

These extensions ideas are great, and well-meaning, but the problem is that you make something that no-one can use, because no clients, or very few clients support them. It reminds me of the days when Microsoft designed HTML extensions, with good intentions no doubt, but the net effect was that you had to use their browser if server-writers used them, or every client had to retro-fit them.

Discworld's MXP was, originally, targetted at WhelkMUD, as it was one of the Trustee's pet projects.

Since then, though, it's all been rewritten after bug reports from players, whose clients couldn't interpret the nonconforming extensions. WhelkMud itself hasn't had a new version since 2005.

Thanks for the explanation, Nick, I'll have to see what I can do about getting it changed to something CMUD/zMUD and MUSHClient can both interpret happily.

That specific case could be redone using just the send command (and, I believe, was, until very recently), but it's not just these popup menus that are implemented this way - score data is too, as well as a few other things. The idea is, I think, in that specific case, that the client can know the last object the player handled, as a side-effect.

Well, strictly speaking the behavior of the functions to handle data in the buffer is the biggest issue. Stuff has, otherwise, done paging in GUIs since as far back as the first copy of Word for Windows. I do think that, should someone ever work out what the rules need to be under such a system, along with the text positioning, that a flag be added, which designates *if* the behavior is in effect, and if so, how commands related to the buffer, line retrieval, etc. actually work. Some things, like triggers wouldn't change much, since they already "post process" after a new line. One just needs to treat any "position change" that moves up or down a line as a "new line". I.e., ten characters get displayed on a line, then text position in moved up one line, then "the prior line" is obviously "complete" at that point, whether or not a newline itself was received. Figuring out "which" line you last received has to be more direct though, which I always thought worked wacky in the client as is, since obviously the last line "received" is not longer the last line in the buffer, its which ever line was changed prior to the last time the cursor moved. The same *new line* could appear on the same existing buffer line 50 times, as something like animation runs, and its never going to be the "last line in the buffer", unless it just happens to be the last line in the buffer those 50 changes are made on.

Oh, and the other distinct issue with paging, once you have *paged* the cursor can't move back up the buffer, into lines that are "not on the page", even if only 5 lines have been received for the page, but some twit asked it to move up 10.

It wouldn't be easy, but certainly not impossible, and the biggest issue is getting the rules of "how" it has to work and what therefor appears in the buffer space, and why, are defined. The only quirk is, in most of them I have used that support scrolled buffers and logs, the "log" contains a complete copy of everything that happened, including position changes, not just the final lines for that "page". It has to, since you can't keep buffering thousands of lines, until a page, before writing the output. You have to limit how much is on screen before its "assumed" that you have reached the end of the page, then write anything above the current "top" line (many would do that, since there was a fixed 25-30 lines on the screen), or you have to write is as it happens, and how they have some way to "replay" the logged data. Obviously, for all practical purposes, Mushclient would have to use the former, and assume that anything that would logically have scrolled "off" the page is "gone", and therefor safe to write to the log.

Again, its only a matter of how you define the rules of how to handle this, and most logging clients with scripts have used roughly the same rules for ages. And the paging itself, has been done quite often in many programs, as far back as GUIs.

Its just not going to be me that does it. lol At the least I still don't have the spare change to buy something with fracking MFC libraries in it to try. :p

Upon re-reading the WhelkMud page, it seems that they intended the tag only for stuff like a help file, where you were required to show the data in a separate window (or split window) which would indeed be a bit easier to implement.

I think MUDs are at a bit of a crossroads right now. It would be helpful, given modern fast PCs, for status information, room descriptions, inventory, maps, and so on, to be shown in separate side-bars or windows, thus moving the presentation closer to what we have become accustomed to in more graphical games.

Of course, to facilitate this, it is handy if the server marks up its data (like MXP does) so the client can instantly know that such-and-such is your status, and something else is your inventory.