MXP processing hang - unescaped ampersands

[ulysses]

Hi,

This is Mudlet 4.17.2 on MacOS 12.7.

Connecting to cthulhumud.com:8889 via the mudconnector I can run the 'help color' command fine. When I run that command in Mudlet, the output hangs, although I can still type commands to the mud and the mud sends output back the Mudlet (this is visible in the cassette recording).

Outputs from mudconnector, Mudlet and the video cassette recorder dat file are attached.

I'm thinking there is a color code which Mudlet doesn't like?

I have disabled all my aliases, triggers and scripts.

Any idea what could be causing this?

Thank you
Ulysses

[ulysses]

After much debugging I finally figured this issue out. It is not due to ANSI codes but MXP processing. It is due to the line '& = blinking' line. The ampersand is not written as & and so it is interpreted as the start of an MXP entity which is never closed. All subsequent output from the MUD is then swallowed by the code looking for the end of the MXP entity, which is a ;.

I have a simple fix for this - look ahead to the next character and if it is a space (after the &) then it cannot be an MXP name.

Otherwise we will have to ask our MUD admins to change all &'s to &

Cheers
Ulysses

[Vadi]

Great work

Is your game using MXP? Because if it is, all ampersands do need to be reported as &

[ulysses]

Hi Vadi,

Yes, MXP is supported on my MUD, so the naked & is wrong in the output. I think Mudlet could check if '& ' (i.e. ampersand space) was present and if so treat it as a bare ampersand. If you agree I can raise a PR - I have figured out a minimal change to check that.

[Vadi]

Have you tried getting it fixed in the game first?

If there is any other case where an ampersand is shown incorrectly and a space doesn't follow it, this workaround for the game won't work it also has potential to break other games.

[ulysses]

Not yet, our MUD isn't very well supported these days, for one reason. I'm interested in what we can do in Mudlet to fix this. I'm also curious why other clients are able to cope with this, but Mudlet is not. For example the Mud Connector web-based session (screenshot above) and MUDrammer iPhone client are both fine. They must be processing the & differently to Mudlet.

I'm aware that other cases where a space doesn't follow an ampersand would also break.

I don't believe such a check would break other games. Why would '& variable_name;' ever be legal? (note the space after the &).

Perhaps you can think of another way of fixing this which would detect an unclosed entity?

[Vadi]

Just as legal as the MUD not escaping ampersand which is not at all. Are other clients supporting MXP?

My first port of call wouldn't be to add workarounds to a third party but fix the issue at the source. Adding workarounds to Mudlet carries the risk of breaking another game, and we shouldn't jump to it as the first solution for the sake of the Mudlet community.

It doesn't sound like fixing the issue at the source has been attempted - let's try that first

[ulysses]

I've asked the admins.
I'm currently running with my local patched build of Mudlet.
Looks like someone else had a similar issue with this on another MUD: http://www.slothmud.org/forum/viewtopic.php?f=7&t=5002
I don't think MUDrammer has MXP, not sure about the mud connector one.

[Jor'Mox]

I'd think that even if Mudlet isn't going to discard malformed MXP, it should at the very least report an error. That way, if this comes up for someone else, at least they will know what the problem is, and can inform the admins on their game.

[Vadi]

Not sure how to do that in a user friendly way that will work for all kinds of users, including the technically challenged ones - but we should do better on our end for sure.