Zugg Software :: View topic - Inconsistent MXP tag behaviour in ZMUD vs CMUD

Newbie Joined: 15 Mar 2010 Posts: 5

Hello,

I'm currently implementing MXP support for my MUD and I've noticed a problem with the way a MXP tag is handled in CMUD. Namely, it seems to "close" all open MXP tags just like a regular newline would do; this does not happen on ZMUD.

Example:
The following sequence sent from the MUD:

Posted: Mon Mar 15, 2010 9:09 pm

This is an intentional change. It was a bug in zMUD that it didn't close Open tags, which could allow people to place BR tags within open chat text. The MUD should almost always be sending lines containing MXP in secure mode. Basically, "secure mode" says "this is coming from a MUD that understands MXP", whereas "open mode" was designed for MUDs that didn't support MXP where people could still place some basic MXP commands within open chat text.

In general, zMUD has several MXP bugs like this which were fixed in CMUD to make CMUD more compliant with the MXP spec and with how MXP works in other MUD clients. We are working on clarifying the MXP spec to deal with obscure cases like this.

Posted: Mon Mar 15, 2010 9:11 pm

Btw, if you are implementing MXP on your MUD, you should probably stay away from the "locked" and "secure for one tag" stuff. Just start each line from the MUD that contains MXP with the secure tag. Start any line sent by other users (like chat) with the open tag (or no tag at all).

Newbie Joined: 15 Mar 2010 Posts: 5

Hmm, I prefer to use locked mode as the default (rather than open) for two reasons:
- to avoid things like which is an open tag; having users placing that in a chat line is not necessarily good ;)
- people who use non-MXP clients often use the < > symbols in their chat, custom title, etc. as an emphasis; over time we've received numerous "bug" reports that certain parts of chat/who list become "broken/cut". Locked mode effectively prevents that.

But that aside, I'd still want users to configure various MUD "message types" (like chat, descriptions, says, tells, ...) with MXP rather than plain ANSI. Messages can of course contain user text (tells, says), so secure mode is not really appropriate. They can also be multi-line (descriptions), hence the problem with closing the tags.

Still, thank you for clarification - I'll try something else; it seems that setting "secure" mode (rather than "temp secure") for the can work as well.

Posted: Tue Mar 16, 2010 3:41 am

On a MUD supporting MXP, you are supposed to be filtering user chat and converting < and > to & lt; and & gt; symbols, and then only allowing the tags that you want to allow.

CMUD (and zMUD) already protect users against abuse, like with your "size=200" example. Don't know what other clients do, but CMUD/zMUD specifically prevent anything that would really mess up the screen in open mode.

The problem with using "lock" mode instead of tagging each line is that the client can get out of sync if it misses a single control code. I'd rather see each line start with the proper mode code.

For message types, take a look at the TAG option in MXP or use the line-tags options. CMUD/zMUD gives the user a good interface for line-tags to determine if the channel should be sent to another window, or colored, or gagged, etc.

As far as multiline, the MUD shouldn't normally add line-breaks itself. You should let the client do the wrapping. If you are sending a line break to force something, like a list of items in a room or something, then you should already be in MXP secure mode. Chat lines from the user should always be a single long line to let the client deal with wrapping. Then you don't need BR within user chat.

Posted: Tue Mar 16, 2010 3:43 am

Newbie Joined: 15 Mar 2010 Posts: 5

Thanks for your replies,

Yes, actually parsing MXP (< > & replacement, detection of valid user tags) would work too; I might end up doing this eventually, although I didn't want to do it at first for performance reasons - I can only change code on LPC level (rather than the LPMUD driver); doing more advanced string parsing on script level is not too effective.

Posted: Tue Mar 16, 2010 8:24 pm

Newbie Joined: 15 Mar 2010 Posts: 5

Posted: Tue Mar 16, 2010 10:34 pm

Are you testing this in the 3.14 Beta version? or the 2.37 version? The 2.37 CMUD version still had bugs with ANSI within MXP. I had thought these bugs were fixed in the 3.14 Beta, so if you still find the problems there, post again and let me know. Doing ANSI within MXP has definitely been tricky in CMUD and hasn't gotten a ton of testing.

Changing the ANSI color definitely shouldn't be changing the background color. ANSI codes should only override those codes specified.

Newbie Joined: 15 Mar 2010 Posts: 5

Whoops, sorry, I've indeed tested them on 2.37... but from tests on 3.14a, the first bug (permanent font) seems to be fixed; the background resetting (my last post) is still here - ie. ANSI foreground resets MXP background. However, it only happens if ANSI starts as "reset" at the beginning of the line. (or was reset sometime earlier)

That is:

Posted: Tue Mar 16, 2010 11:55 pm

OK, that actually makes sense and will help me track down the problem. The ANSI reset is causing the ANSI background color to be set to the default, and when the later ANSI code gets executed, CMUD is taking the background from the previous ANSI setting and not the MXP setting. The code is all very messy.