[Home] [Downloads] [Search] [Help/forum]

Gammon Forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  MXP and Pueblo
. . -> [Subject]  Element definitions cannot define other elements
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

Element definitions cannot define other elements

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page


Posted by Ian Kirker   (30 posts)  [Biography] bio
Date Tue 12 Feb 2008 12:08 AM (UTC)

Amended on Tue 12 Feb 2008 12:29 AM (UTC) by Ian Kirker

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

<!EL livingpopup '<!EN ob &arg; private><send href="look &ob;|nod &ob; |smile &ob;" hint="Right click for menu">' att=arg>

is designed such that:

<livingpopup "evil-looking rat">evil-looking rat</livingpopup>

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

E  1039: (  441) Element definitions cannot define other elements: <!en>

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.
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #1 on Tue 12 Feb 2008 02:56 AM (UTC)

Amended on Tue 12 Feb 2008 03:03 AM (UTC) by Nick Gammon

Message
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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Isthiriel   (111 posts)  [Biography] bio
Date Reply #2 on Tue 12 Feb 2008 04:32 AM (UTC)

Amended on Tue 12 Feb 2008 04:34 AM (UTC) by Isthiriel

Message
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 :(
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #3 on Tue 12 Feb 2008 05:41 AM (UTC)
Message
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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #4 on Tue 12 Feb 2008 06:12 AM (UTC)
Message
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:

Quote:

If a very long piece of text is sent from the mud down to the client, the client should do the paging of the information, not the service


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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Ian Kirker   (30 posts)  [Biography] bio
Date Reply #5 on Tue 12 Feb 2008 07:59 AM (UTC)

Amended on Tue 12 Feb 2008 08:00 AM (UTC) by Ian Kirker

Message
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.
[Go to top] top

Posted by Shadowfyr   USA  (1,783 posts)  [Biography] bio
Date Reply #6 on Wed 13 Feb 2008 04:48 PM (UTC)
Message
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.


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
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #7 on Wed 13 Feb 2008 09:37 PM (UTC)
Message
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.


- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] 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.


10,733 views.

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

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

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at FutureQuest]