Gammon Forum : MUSHclient : Suggestions : MXP Tags

Log on

Gammon Forum

Entire forum

MUSHclient

Suggestions

MXP Tags

MXP Tags

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

Posted by

Shadowfyr USA (1,786 posts)

bio

Date

Wed 12 Dec 2001 07:46 PM (UTC)

Message

It occured to me that the way MXP behaves when active is not only inconvenient, but less than useful. Since having recieved a < the client automatically treats everything after it as a tag, short room descriptions, like <<Court Yard>>, only show up as '<'. This is not unexpected, but there is no reason why is should happen, since having failed to identify a valid tag, it should be possible to pass the contents back to the normal output display. Now, why would you want to change the way it works if this is 'normal' for MXP? Because it would also help with debugging, since you could then immediately see the bad tag, if you made a mistake. I.e. '<clor Peachpuff>' instead of <color Peachpuff>. ;)

top

Posted by Nick Gammon Australia (22,975 posts) bio Forum Administrator

Date Reply #1 on Wed 12 Dec 2001 08:52 PM (UTC)

Message

In the MXP/Pueblo configuration dialog, set the "MXP debug level" to "errors", "warnings" or higher. Then you get all sort of useful information to help debug MXP coding.

In the example you gave you would see this in a separate window:



E  1023: (  519) Unknown MXP element: <clor>

The error number is 1023 (you can filter those in a script), and 519 is the line number, which you can use "Display -> Go To Line" to go to the exact line in the output (Ctrl+Alt+L).

The program handles unrecognised output in this way for a very good reason - forward compatibility. For example, if it displayed <<Court Yard>> on your screen, then you would not realise you had made a server programming error, and then one day if we wanted to add an MXP tag "Court" (or a custom tag of that name) then suddenly all the instances of <<Court Yard>> would disappear.

Better to have it happen now, fix the problem (using the debug window) and be ready for future changes.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Shadowfyr USA (1,786 posts)

bio

Date

Reply #2 on Wed 12 Dec 2001 10:58 PM (UTC)

Message

Right... Didn't think of that. Then why not treat << or >> like many programs treat //. Assume that the user intended a single <. I am not aware of any instance in which commands are/can be nested like <<color Peachpuff> Some other command>, so it shouldn't effect the function of MXP. The problem when it comes right down to it is that non-MXP aware muds will do silly things like using < and > and it is useful to have MXP turned on for messaging, mud-mail, etc. Would be even more useful once the designers of zmud fix the bug that prevents MXP from working in its default mode. :p As of now only Mushclient users can send each other color codes, but since the only way to turn MXP off is to do it in the menu or through illegal (on most muds) escape codes... I would rather leave it on, but am forced to have it turned off. I kind of hoped some method could be used to get around the problem. ;) Odd thing is Mush starts to do this, ignoring the first instance of < when no command is found, then eating everything including the last >, which is not reasonable behaviour. ...or moybe I have that backwords and it eats everything but the last >. Don't remember at the moment.

top

Posted by Nick Gammon Australia (22,975 posts) bio Forum Administrator

Date

Reply #3 on Thu 13 Dec 2001 03:16 AM (UTC)

Amended on Thu 13 Dec 2001 03:17 AM (UTC) by Nick Gammon

Message

Frankly, if the MUD server is not handling descriptions properly, then all sorts of things will go wrong, for example, prompts:



<10hp 20mv 30m>

Instructions:



Press <north> to leave this room. Type <help> for help.

Even changing MUSHclient to recognise <<Courtyard>> as <Courtyard> is only fixing a particular problem (and zMUD won't do that).

I think the solution is for the MUD server to be changed to convert all < into < and all > into > excepting when it is actually trying to send an MXP tag. I have done a lengthy page explaining how to do that, with patches for SMAUG and ROM available. Also, PennMUSH already handles MXP/Pueblo correctly.

Quote:

Odd thing is Mush starts to do this, ignoring the first instance of < when no command is found, then eating everything including the last >, which is not reasonable behaviour

This isn't odd, it is behaviour by design. When it gets an "<" it treats everything until the next ">" as a potential MXP command (unless it gets certain characters first, such as a linefeed or "escape" character).

It is all very well saying it "should realise" but something like this:

Quote:

<go north for help>

might one day be a valid MXP command (called "go", with arguments "north for help").

I am opposed to putting kludges into this client (and other clients) that are not documented, just to help server implementors who have not properly converted things like room descriptions.

MUSHclient has well-defined behaviour (see the MXP part of the forum), and along with its error reporting - which is quite detailed - lets server implementors get their servers right, and then all this worry can go away. :)

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Shadowfyr USA (1,786 posts)

bio

Date

Reply #4 on Thu 13 Dec 2001 03:40 AM (UTC)

Amended on Thu 13 Dec 2001 07:19 AM (UTC) by Shadowfyr

Message

Well, it was worth a try. ;)

The probability of getting anyone on the mud I play to listen, let alone change anything is not real great. They have had a mess of recent problems that resulted in the deletion on a number of people (including designers), as well as changing to a register only character creation. Also, using &lt and &rt assumes all clients will support them. The only way to really 'fix' the problem that way would be the make the mud aware of MXP and most people I have talked to about it just don't see the point. Even though I pointed out that they did not have to use every feature, just include better color management. Unfortunately the only mud I have found that claims active support of it seems to have also been designed by someone that has no sense of style, over uses colors (not even non-ansi ones) and generally made me want to leave within the first 2 rooms.

And by doing it 'right', does that imply that everyone that created a mud prior to MXP did it wrong? Huzzah, for creating an option that is backward compatible! Must be a Micro$loth design. ;) lol

Guess my basic problem is that they chose to mimic HTML tags and use a symbol that has been in common use for a very long time to do something that is not completely compatible with existing games. Yes <> makes a nice bracket of a command, but almost no mud/ansi based game, etc. I have ever seen does not use it. Not that you can do anything more about the implimentation than I can, but it is a major pain. It is a bit like having them write a new editor for C++ and deciding to make = a special internal command. Not real bright.. ;)

top

Posted by Nick Gammon Australia (22,975 posts) bio Forum Administrator

Date

Reply #5 on Thu 13 Dec 2001 06:12 AM (UTC)

Amended on Thu 13 Dec 2001 06:13 AM (UTC) by Nick Gammon

Message

I don't really understand the problem here.

MUSHclient (like other clients) will still work fine on "ordinary" MUDs, and will render < and > characters in the usual way. No problem.

However if the MUD sends out the "MXP negotiation sequence" which advertises that it is going into "MXP mode" then it should then (and only then) convert < and > into < and >.

The whole idea here is that some MUDs, not all of them, will support MXP. Those that do will negotiate (using telnet sequences as documented in the MXP spec) to see if the client supports MXP. If so, both server and client switch to "MXP mode" and then the client expects the server to render < and > as < and > to avoid confusion with the HTML-like MXP tags.

Quote:

Also, using &lt and &rt assumes all clients will support them. The only way to really 'fix' the problem that way would be the make the mud aware of MXP and most people I have talked to about it just don't see the point.

No, only after the client agrees it will support it.

Quote:

And by doing it 'right', does that imply that everyone that created a mud prior to MXP did it wrong? Huzzah, for creating an option that is backward compatible! Must be a Micro$loth design. ;) lol

No, but if the MUD claims to support MXP, then it should support it properly, as per the MXP spec. It is backwards compatible, because if you don't support MXP then both the client and server do things "the old way".

Quote:

Guess my basic problem is that they chose to mimic HTML tags and use a symbol that has been in common use for a very long time to do something that is not completely compatible with existing games. Yes <> makes a nice bracket of a command, but almost no mud/ansi based game, etc. I have ever seen does not use it.

Sounds like you might have forced MUSHclient into "MXP mode". Then you might have these problems. On the MXP/Pueblo configuration page, just set "Use MXP" to "On command", not "always".

Quote:

Unfortunately the only mud I have found that claims active support of it seems to have also been designed by someone that has no sense of style, over uses colors (not even non-ansi ones) and generally made me want to leave within the first 2 rooms.

Some I have seen are a bit like that, yes. Have you tried "Blood Moon"?



IP: lark.crodo.com 

Port: 1313

That uses MXP extensively and has pretty reasonable colours. MXP actually works well there, they have hyperlinks for objects on the ground, your inventory, help topics and so on.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Shadowfyr USA (1,786 posts)

bio

Date

Reply #6 on Thu 13 Dec 2001 07:40 AM (UTC)

Message

Umm... Ok, I must have been getting tired on that last post, since I was not clear. Yes, I was forcing it on, since the only way to use non-ansi color (and to use colors with other people that have an MXP supporting client), is to have it switched on. The fact that it eats some things in some cases in not a 'problem', just an annoyance. ;)

All I am saying is that the fact that they chose to use < instead of a special character like ansi does is inconvenient, since if you do have it on for some reason it interprets things on existing non MXP muds as commands. It is also odd, since they considered the activation code being and escape code acceptable, but not the command codes. From a mud design stand point it is no more difficult to begin/terminate a command with escape< and escape> than to use < and > by themselves and it would have prevented the clients from misinterpetting things that where used for other purposes on older muds. They seem to have simply borrowed HTML tag syntax and adapted it, without any thought to the inconvenience it could cause a few crazy people like me that want to bypass the restrictions on ansi codes (usually, but not always done to prevent keyboard remapping, not color use). Nor the inconvenience for anyone wanting to add it to existing muds of going through who knows how many lines of code looking for errant <s and >s in the descriptions and adding special code to use the HTML equivalent when an MXP user is connected.

Imho this is an oversite. Though not one you or I can fix, or which the developers of MXP are likely to change. Everyone is just stuck with the method they decided to use.

That being said... I should probably have moved this into a different forum after your first reply. ;)

top

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #7 on Thu 13 Dec 2001 08:38 PM (UTC)

Message

I'm starting to see what you are doing here. You are not on an MXP-enabled MUD, but are trying to use the MXP commands to add colour etc. for yourself.

I can see that the MXP spec wouldn't quite work for you, as it wasn't intended to be used in that way.

You could add colour to some extent with MUSHclient just with some fancy triggers.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

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.

14,437 views.

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

Go to topic: Search the forum

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.